For this week’s “In the News”, perform research on one of the following:
- new testing requirements (e.g. SSAE18 SOC1 or SOC2)
- new testing requriements put into place due to regulations
- how security assessments and testing integrates with other domains, such as cloud network architecture, or software development lifecycle?
I favor news with flashier headlines. This, despite a lack of flash or sales pitch, is the best explanation of System and Organization Controls (SOC) Reports. The first bullet explains the AWS take on what the reports provide and the Primary Report Purpose and Audience go a long way to explaining the reports generally, not just via AWS.
https://aws.amazon.com/compliance/soc-faqs/
Wow Steve, this sent me on a wild deep hole of discovery. The faqs were for more informative then they typically are in a faqs list. I really like the way Amazon performs in this sector. Studying them as a project for a previous class I learned a fair amount about their AWS infrastructure and was enamored by its ever going size. Say what you want about Bezos his divorce, his odd connections to the government, the man sure can build an empire. Check out all their services running in the SOC3 list starting page 5.
New testing requirements – Payment Card Industry (PCI) Security Standard Council
———————————————————————————————————————
Key Highlights:
• Released January, 2019
• PCI SSC publishes the PCI Secure Software Standard and the PCI Secure Software Life-cycle (Secure SLC) Standard as part of a new PCI Software Security Framework.
• Relevant to vendors who develop applications for payment processing and sell those applications to businesses who take and process payments.
• Secure Software development practices
o Where open source software components are utilized as part of the software, the assessor shall examine vendor evidence, including process documentation and assessment results to confirm these components are managed as follows:
• An inventory of open source components used in the software is maintained
• A mature process exists to analyze and mitigate the use of open source components with known vulnerabilities.
• The vendor monitors vulnerabilities in open source components throughout their use or inclusion in the vendor’s software to determine when new vulnerabilities are identified.
An appropriate patching strategy for the open source components is defined.
• Part of a new PCI Software Security Framework, which includes a validation program for software vendors and their software products and a qualification program for assessors.
• Illustrates that a software vendor has mature secure life cycle management practices in place to ensure its payment software is designed and developed to protect payment transactions and data, minimize vulnerabilities and defend against attacks.
• Strives to demonstrate an ongoing protection of payment data by the software that stores, processes or transmits that information, and for software providers to have a way to demonstrate independent security evaluation of the software to achieve that goal.
• Intended for payment software that is sold, distributed, or licensed to third parties for the purposes of supporting of facilitating payment transactions.
• Outlines Key security principles in the Secure Software Standard which includes asset identification, secure default configuration, sensitive data protection, authentication, access control among other principles
• A collection of software security standards and associated validation and listing programs for the secure design, development and maintenance of modern payment software.
https://blog.pcisecuritystandards.org/just-published-new-pci-software-security-standards
Oby, I have to imagine this is a sector of the technology world where testing requirements are ever changing. There is nothing more important to an organization then to keep financial transactions safe guarded. Yes, the breach of confidential information is scary, but when you’re dealing with people’s money, things really get scrutinized. And I also feel that this is one of the most highly targeted areas!
https://www.accountingtoday.com/news/sarbanes-oxley-compliance-hours-on-the-rise-despite-technology
In a recent survey, it was discovered that 59% of the companies polled are revealing that time invested in SOX compliance is increasing 10% year after year. However, 47% of the audit teams are neglecting to use or upgrade to advanced automation or robotic processes for data analytics. Yet, compliance cost is trending downward for large international companies. With new processes and standards, these times are likely going to increase. The solution, leverage existing technology to ease SOX compliance. The technology exists and the cost for compliance is shrinking. Capitalize on this equipment to reduce your need for auditors or to automate tests when applicable. The organizations leveraging technology for SOX compliance today find “data analytics was cited as the most widely used tool (41 percent), followed by automated process approval workflow tools (38 percent) and access controls, user provisioning and segregation of duties review tools (36 percent).”
I would love to know how much money is spent every year on compliance to regulations. The amount must be staggering. Even more interesting still would be the number of small organization that struggle to meet compliance because of the financial burden.
I am surprised but not surprised that 47% of audit teams are not utilizing automation or other advanced processes for data analytics. Data analytics has tremendous benefits and in this case, using the analytics to see how you are doing from a compliant standard can definitely help the company in various ways. Even today, people who use analytics and look for the most newest tools,even find themselves behind in the game compared to other companies. Its growing and popular, but like all advanced technology – there are slow adapters (maybe even too slow).
Brock, great insight! You write that 47% of the audit teams are neglecting to use or upgrade to advanced automation or robotic processes for data analytics. Perhaps this is a case of self-preservation and/or there is risk associated with changes in audit which are currently too high to warrant the change.
Enhanced requirements, NIST SP 800-171B, has made it tougher for contractors and third party vendors dealing with government entities. According to the article, the DoD has begun to step-up enforcement of existing cyber security regulations as well as making requirement stricter. The enhanced requirements applies to select critical programs and high value assets. In order to stay compliant they must implement all of the DFARS 7012 requirements, including everything from NIST 800-171. DFARS 7012 is a requirement for contractors to adhere to NIST cybersecurity standards handling Covered Defense Information (CDI). The DOD is in the process of establish a certification program that 3rd party assessors will validate contractor compliance.
More information the new requirements below:
https://www.prnewswire.com/news-releases/new-dod-cybersecurity-policies-getting-tougher-on-contractors-300875261.html
I think the DoD enforcing stricter Cyber Security Regulations are great. 3rd party vendors and contractors have access to critical data. They should make sure they are following all the proper security protocols and procedures before engaging in business with them. So often 3rd party vendors are hacked and it’s not the 3rd party vendor that get the weight of the blame it’s the Big Name client. For example, LabCorp, millions of users (including myself) PII information was exposed due to a breech by LabCorp’s 3rd party vendor. Now, all the attention is on LapCorp not the vendor.
I agree with Sheena, I think this is great news. I mean you are talking about some of our biggest and critical programs. The requirements should be extremely strict when it comes to vendors and third parties. It has been too many times where a company was hacked do to a vendor or third party weakness. Even if these actors to do have direct access to critical data/information, they have access to the system and that is enough for the threat actor to do damage. Kudos to the DoD!
The Shift to SSAE 18: Five Ways Your Company May Be Affected
Systems and Organization Control (SOC) reports are now issued under the Statement on Standards for Attestation Engagement No. 18, Attestation Standards: Clarification and Recodification (SSAE 18). The switch to SSAE 18 began on May 1, 2017. This means that SOC 1 reports are no longer issued under the guidelines of SSAE 16 and SOC 2 and 3 reports are longer issued under AT 101.
The intent behind releasing SSAE 18 was to consolidate multiple attestation standards and clarify assurance services that CPA firms perform. The change was also intended to address concerns over the complexity and length of the AICPA standards that SSAE 18 replaces. To sum it up, SSAE 18 is cleaner version than previous standards.
Until now, the terms “SSAE 16” and “SOC 1” have often been used interchangeably. That was generally fine as SSAE 16 was specific to SOC 1 reports, but since SSAE 18 covers all attestation engagements the change to SSAE 18 means that SOC 1 reports should not be referred to as SSAE 18 reports. These reports should simply be referred to as SOC 1 reports.
The SOC 1 reports pretty much look identical to SSAE 18 as they did under SSAE 16 and the changes to the reports are minor. Five main changes are:
1. Monitoring the effectiveness of internal controls at subservice organizations.
a. Service organizations must implement sufficient controls to monitor the relevant controls at their subservice organizations.
2. CPA firms need to identify and assess the risk of material misstatement and perform procedures in response to those risk
a. They are instructed to better identify potential areas of risk specifically in regards to material misstatement.
3. Complementary Subservice Organization controls and modifications to management’s assertion
a. Given the increase in outsourcing of procedures and the shift of control responsibilities to subservice organizations, SSAE 18 introduces additional requirements to include complementary subservice organization controls in SOC reports.
4. Evaluating the reliability of evidence produced by the service organization
a. SSAE 18 clarifies the requirements to ensure that evidence provided by service organizations is complete, accurate and detailed.
5. Signing of Management Assertion
a. SSAE 18 clarifies that the management assertion needs to be signed by management of the company.
http://holtzmanpartners.com/shift-ssae-8-five-ways-company-may-affected/
I can across and article that discuss new requirements for segmentation penetration testing for PCI compliance. According to Mat Clarke, from sysnet global solutions, “The goal with segmentation testing however is to test any controls which are said to be in place and are being relied upon to separate (segment) areas of the network which are not in-scope for PCI DSS requirements from the parts of the network which are.
An example of this could be where a guest network has been created and separated from the main corporate network. A segmentation test in this case would focus on testing the connectivity between the guest and corporate network in order to confirm whether the controls restricting traffic between the two are working as intended.”
Infosec.com defined the frequency of Segmentation penetration testing for PCI compliance “Segmentation penetration testing needs to be done once every year for merchants and once every six months for merchant service providers, as per PCI.”
https://sysnetgs.com/2017/10/demystifying-pci-dss-requirements-penetrationsegmentation-testing/
https://resources.infosecinstitute.com/segmentation-penetration-testing-for-pci-compliance/#gref
This is an excellent article that explains a problem and fully outlines a resolution with its process. Everyone should take time to read this link. Thanks for posting.
Sheena,
Great post. Segmentation testing is very important as it ensures that less-secure networks such as guest networks do not have access to communicate with high secure networks such as corporate networks. Segmentation testing should be performed regularly to ensure that the security controls are in place and working properly that segment the business needs.
This was a pretty interesting article that had a really interesting subsection I thought fit nicely into this week. It talks about Hold vendors accountable for their IoT equipment. When you think about security assessments a lot of times they need to be completed when a new vendor is incorporated into the organization and network. It is important to make sure you hold them accountable to updates and make sure that the device they are trying to add in like a raspberry pi print server gives more access then it is supposed to have on the network. This could open a back door into the organization and leave them very vulnerable. At the end of the day it is important to think of the waste and plan for it but hope the best is the outcome.
Source: https://www.networkworld.com/article/3404198/7-things-you-can-do-to-enhance-iot-security.html
Hi Jonathan:
Indeed, the article is quite interesting as you already mentioned. I say this because I researched and wrote a term paper on IOT last semester and it was an eye opener for me. There is so much work to be done with regard to securing IoT devices; the scariest aspect of it as you aforementioned lies in the fact that IoT devices have the ability to introduce a backdoor to an organization’s security ecosystem.
A quick search on the internet will turn out scary results of ioT devices with reported backdoor exploits. I like the fact that the article introduces what one might call a guideline for handling ioT security to curb known and unknown malicious or unauthorized activities.
Target, among others were victims of weak vendor security. If vendors continue to use cheap solutions on their network then this is going to keep happening. It is very likely going to cause a wider scope to the already exhausting vulnerability scans. Adding security assessment requirements will be highly necessary for vendor agreements in the future.
https://www.computerworld.com/article/3279888/regulatory-uncertainty-could-stymy-blockchain-adoption.html
Blockchain is something that has interested me. With the advent of this new crypto currency in the world, I wonder how and when governments are going to step in and get some kind of handle on this. If you’re really not familiar with blockchain, you can read up on it here: https://en.wikipedia.org/wiki/Blockchain
Right now, there is no regulations around blockchain, but it’s taking the world by storm. It’s openness and resistance to tampering has many enamored with it. It’s secure and private, so much so that it’s become the favored means of payment for hackers in demands or ransom. Once transactions are complete, no one can trace or reverse the transactions. Many crypto currencies are evolving, such as Bitcoin or Ethereum. And the number is growing each day. My belief here, any government regulation or tampering will just muddy the waters. While it has it downfalls, I think the good outweigh the bad, and there is a good thing going here. We’ll see what happens in the future as governments scramble to keep up.
Some would say that a federally backed crypto currency is a defeating purpose but that seems to be what the general population wants in order to trust this new technology. However I don’t belive this is something that can self regulate. All these blockchaining techs are developed by people. The same people that can add backdoors to systems and intentional vulnerabilities. Recently there was a coin that had a major vulnerability enabling coins to be stolen. While the responsible coin company used the vulnerability to “steal” their coins from their customers in order to distribute them back, this is a fine example of why regulations is needed. I think regulations on blockchains is inevitable. Especially looking into this article and finding out the weight of support in the US.
Hi Brock:
I’m on your side with regard to the inability of blockchain technology to self-regulate. Like you rightly touched on the vulnerabilities that currently exists in some of these coins and as promising as the technology looks, the inherent risks forbears a lot of companies to fully dabble into the convenience that the technology proffers. The current associated risks outweighs the current gains giving the fact that we are talking money for the most part, however time will tell.
I agree, not a big fan of federal involvement into crypto as I believe they will try to centralize, defeating the whole purpose the decentralized aspect of many cryptocurrencies we see today. I do understand them trying to implement regulations in order to better secure consumers. I would like to see regulations around the development of protocols/coins. The idea of blockchain itself is inherently secure, has an audit trail, and is effectively anonymous. Much of vulnerabilities comes with bad code when trying to develop new coins and protocols. Standards/regulations should definitely be met before anything new can launch. There are too many frauds out there.
Reasearch on how security assessments and testing integrates with other domains, such as cloud network architecture, or software development lifecycle.
Security assessments and tests provide a holistic view of an organization’s security tools and their effectiveness. These enterprise-level security assessments can be further defined into two sub-categories: access control tests and security assessments. Access control tests encompass a number of processes and methods that assess how strong an organization’s access control systems and rules work and include the following disciplines: vulnerability scanning, penetration testing, and security audits.
Recently firms like AWS have opened their network for Penetration Tests. While previously a test required prior permission, now no permission is required. This encompasses 8 services including EC2 and RDS – the two biggest AWS services. https://aws.amazon.com/security/penetration-testing/
One caveat is that vendor offered services are restricted from penetration testing according to this article: https://rhinosecuritylabs.com/penetration-testing/penetration-testing-aws-cloud-need-know/
For security companies it becomes a task of differentiating these services and defining the scope.
This article discusses how the SDLC is a way to ensure that all the security controls and requirements are correctly placed within a new system or application. Integrating security in the SDLC helps organization consider security as one of the important phases in the development phase from the beginning of the cycle instead of having to incorporate security after the application or system has been implemented. SDLC accomplishes this by ensuring that everything is secure at the end of each phase before moving on to the next phase.
The SDLC is broken into different phases:
– Project Initiation: This includes the project objectives, users of the system or application and what needs attention in terms of the confidentiality, integrity and availability
– Analysis: Focuses on project development, staff, costs, maintenance, risks that this new project may pose on the organization
– Business and Operational Requirements Specification: Develop business and operational requirements to make sure that the business goals are met
– Functional Specifications: Making sure that the operational and business objects reflect the users’ functions and experience
– Detailed Design Specifications: Develop detailed design specifications that translate functional specifications into a logical and physical design
– Development: This phase is where the security features are enabled
– Unit Testing: This phase is intended to identify program problems within a system or application
– System Testing: Ensuring that all phases have been implemented properly and ready for implementation
https://securityintelligence.com/the-system-development-life-cycle-a-phased-approach-to-application-security/
Hi Dima:
Interesting article on SDLC. Something I’m noticing lately per Application Development is that more businesses are infusing Agile methodologies which has a entirely different set of stages when compared to SDLC. One common agile methodology which has the distinctive feature iterative process of developing is SCRUM. I personally favor the agile methodology in-to-to having worked with both SDLC and Agile with regard to Application Development. I found the Agile team to be more responsive compared to my SDLC team as we tended to a lot of missed deadlines and seemed to retrofit security at the end of this particular project which of course caused bigger issues down the line.