Securing the Modern Enterprise: SToRM Framework
•Download as PPTX, PDF•
0 likes•46 views
The proliferation and complexity of software-enabled systems have amplified risk for many organizations. Conventional approaches to software security don’t work, typically encompassing no more running vulnerability scanning. Executives need a better way to understand which products, systems, and teams are putting their enterprise at most risk – and deploy appropriate action plans. SToRM represents a new approach for enterprises to more effectively assess and protect software-dependent IT systems. Change your approach – evolve from a vulnerability-focused approach to risk-based one. Learn pragmatic steps to ensure you’re mitigating the most risk with limited resources, time, and budget. Topics include: • Why traditional approaches aren’t working • How to identify risks at the business workflow and IT system levels • Techniques to calibrate assessment and mitigation efforts
Recommended
Recommended
More Related Content
More from Security Innovation
More from Security Innovation (20)
Recently uploaded
Recently uploaded (20)
Securing the Modern Enterprise: SToRM Framework
- 1. 1
- 2. 2 • Securing software in all the challenging places…. • ….while helping clients get smarter Assessment: show me the gaps Standards: set goals and make it easy Education: help me make good decisions Over 3 Million Users Authored 18 Books Named 6x Gartner MQ About Security Innovation
- 3. 3 • CEO by day; engineer by trade (and heart) • Mechanical Engineer, Software Engineer • Ponemon Institute Fellow • Privacy by Design Ambassador, Canada • In younger days, built non-lethal weapons systems for Federal Government About Me
- 4. 4 Agenda Why Traditional Approaches Aren’t Working Identifying Business Workflow and IT System Level Risk Calibrating Assessment and Mitigation Efforts to Risk
- 5. 55 Why Traditional Approaches Aren’t Working
- 6. 6 Software Powers the World • Consider all the software dependent security disciplines: physical, data, infrastructure, networks, cloud • Factor in all the different data flows and technologies • Toss in software-borne exploits: Heartbleed, Shellshock, Stuxnet • Compound the challenge with business requirements • Regulatory, customer, legal obligations • 3rd-party services and supply chain dependencies • Intellectual property protection • The dilemma: Leaders need to know which products, systems, and teams are putting their business at most risk
- 7. 7 • As an industry, we are over reliant on: • Scanning • Miss certain vulnerabilities, false positives, non contextual ratings • Fail to address code-, system-, business logic- and workflow- vulnerabilities • Vulnerability hunting: amounts to whack-a-mole • Network defenses: defense in depth is critical, but often bypassed • Without a systemic & adaptive approach, the tail continues to wag the dog Conventional Approaches to Software Risk Management
- 8. 8 • SToRM prioritizes high risk software via rapid, relative risk & threat analysis • Assessment and controls are commensurate with application/data risk • Roadmap is contextual and weighted • From security engineering activities, to policies and tools usage, to training New Approach to Software Security Risk Management
- 9. 9 Polling Question #1 • On a scale of 1-4, how much insight into the real risk of software do you feel your organization has? • 1 (no insight) • 2 • 3 • 4 (full insight)
- 10. 1010 Identifying Business Workflow and IT System Level Risk
- 11. 11 The value of understanding security risks is only realized when you can decide where (and whether) to dive deeper into specific problems and take appropriate risk mitigation actions SToRM Overview
- 12. 12 SToRM in Action: Application Asset Rating • Applications rely heavily on their environment to operate • These resources all provide input to the software, which can fail • Step 1: Portfolio Analysis • Document critical assets; should represent your full portfolio • Step 2: Prioritize business applications • Rate them on a relative scale that makes sense to you; ensure it’s used consistently • You can also base asset rankings on: • Business Impact Analysis (BIAs) that may have already been performed • Sensitivity of data processed by assets, value to the business, or impact on operations
- 13. 13 Secure SDLC Gap Analysis • Can be a simple questionnaire against best practices (e.g. PCI SSF) or more advanced model like OpenSaMM • Result should be gap report and creation of secure development policy • Documenting a policy is not a guarantee that it’s being followed • Use similar approach for 3rd-party providers for acceptance testing
- 14. 14 SToRM in Action: Risk Discovery & Assessment • Review of application- or systems-level technical specs to understand how it’s been designed and deployed • To ensure implications are correctly assessed, construct a unified view of threats and risks at business workflow and technical system levels • Different threat modeling techniques can be used for a 360-degree view • My favorite is STRIDE, however PASTA and others are great too • Carnegie Mellon University’s Software Engineering Institute lists 12 modeling methods https://insights.sei.cmu.edu/sei_blog/2018/12/threat-modeling-12-available-methods.html
- 15. 15 SToRM in Action: Risk Assessment Includes review and/or development of: • Asset and data classification schemas • Security classification schema for applications which specifies classification criterion, e.g. • type of data processed, internal vs. external • Tabletop exercises to discuss additional threat vectors • Current secure SDLC security practices and controls • Portfolio risk rating framework that considers impact, threats, requirements, etc
- 16. 16 Examine Application and its Environment • Generate a business-level threat model and as many deep threat vectors as possible • Identify and prioritize high-risk applications based on business impact, security threats, compliance mandates and operational risk • Recommend security assessment activities based on application & data security risk • May range from a rapid fully- automated scan to a deep manual inspection • Create a risk rating framework that calibrates assessment efforts to criticality
- 17. 17 Threat Analysis • Threat modeling of the application workflow • Couple with attack modeling and design/code review • Trace all the ways users and admins might accidentally or intentionally exploit faulty control logic or coding errors • Insight should be used to determine next steps for your application’s lifecycle: • Deeper or broader testing • Rebuilding • Replacing it with another application • Accepting the risks as-is • Deploying different/additional mitigation controls • Taking it out of service completely
- 18. 18 Outcomes of Risk Discovery & Assessment • Digital assets that are most at risk and require protection • Most likely threats to those at-risk assets • Specific malicious attacks that could be used to realize those threats • Design & deployment conditions under which attacks would be successful • Mitigations or additional testing that must be conducted to reduce identified threats or prove/disprove their existence
- 19. 19 SToRM in Action: Application Re-ordering • After Threat Modeling, reassess application risk rating • Create tiers and place each application in one based on criteria • Data classification reflects level of impact if data is compromised • Attack exposure is an important factor in relative risk • Combination of data criticality and attack exposure results in risk rating grouping
- 20. 20 Sample Risk Rating: Application #4 (of 9) • Internal support help-desk application for support and ticketing • Customer records are stored in a central database in an internal data center; however, it is only customer name and email address • Built in-house and the product it supports will be end-of-lifed soon
- 21. 21 • Operational e-commerce application • Built by 3rd party • Data is sensitive and once collected, is stored in an encrypted database Sample Risk Rating: Application #7 (of 9)
- 22. 22 Grouping Software Applications Oversimplified Example • 5 basic categories and assign a 0, 1, 2, or 3 based on risk factors:
- 23. 23 Polling Question #2 Which Software Risk Management technique do you see as the most important? • Threat Modeling • Application Risk Rating • Data Classification • SDLC Gap Analysis/Optimization
- 24. 2424 Calibrating Assessment and Mitigation Efforts
- 25. 25 Persistent Asset: Application Risk Rating/Grouping • Teams have framework/blueprint to implement: • Implement risk-based practice • Make informed decisions • Calibrate security assessment to business exposure • Revisit when new applications are planned • As you get more mature, add criteria, adjust ratings, etc
- 26. 26 SToRM in Action: Security Test Calibration • You’ve considered criticality of data stored, transmitted/processed, and exposure • There is no standard formula; risk tolerance and data mapping is contextual • Goal is to have recommended testing frequency and depth for each tier
- 27. 27 Persistent Asset: SDLC Gap Analysis & Remediation Roadmap • Sequencing of new activities and tools should be considered carefully • Don’t focus on one pillar (technology, people, process/standards) • They are highly dependent on each other • Consider skills development a critical success factor • Introducing tools without training on objective & activity will have limited impact • Consider each job function and technology stack • Java developer needs different training than .NET developer, even though both build Web apps • IT engineer that protects software in play will require different training than a software/DevOps engineer focused on building security into the process
- 28. 28 Persistent Asset: Business Level Threat Model • Needs to be living assets that can be revisited in the future • Threats are not vulnerabilities – they live forever • Considering a significant new feature? Read about a new attack? • Return to the threat model and make necessary tweaks to understand impact Courtesy: Sean Gallagher
- 29. 29 2/21/2020 Vulnerable to Heartbleed? Threat #12 Compromise App Password 1.1 Access “in-use” password 1.2 Guess password 1.3 Access Password in DB 1.1.1 Sniff network 1.1.2 Phishing attack 1.2.1 Password is weak 1.2.2 Brute force attack 1.3.1 Password is in cleartext 1.3.2 Compromise database 1.3.2.1 SQL injection attack 1.3.2.2 Access database directly 1.3.2.2.1 Port open 1.3.2.2.2 Weak db account password(s) Use TLS to encrypt OpenSSL 1.0.1f Require strong Password 8+ char, upper, lower, number, special char Use Prepared Statements .NET parameterized queries OleDbCommand() with bind variables Restrict Port Access Firewall configuration
- 30. 30 Persistent Asset: Development & Procurement Policy • Almost every organization has a combination of home- grown, COTS, and outsourced/bespoke applications • Each poses similar risks and should have cybersecurity acceptance testing criteria based on your SDLC policy • Documentation of security standards/checklists for dev teams (regardless of where they reside organizationally) is a byproduct of this exercise • Be sure to enforce them and review them regularly
- 31. 31 Final Thoughts • Organizations are too reliant on software to apply a one size fits all strategy • If you don’t break the Find & Fix hamster wheel, you know what happens • Eliminating risk is impossible; yielding high Mitigation on Investment (MoI) isn’t • There are no standard formulas for managing software risk • The by-products of SToRM activities ensure teams: • Are judicious with their limited resources • Understand where top priorities are • Have proper context/vision to do their job • Can make informed (aka risk based) decisions
- 32. 32 How Can We Help? Secure SDLC Risk Review • Fill compliance gaps with tools, activities and skills • Roadmap with optimal sequencing Computer Based Training • Covers all major technologies, roles, frameworks • Maps to PCI DSS, GDRP, OWASP, ISO, NIST, NERC, CSSLP, CWE, HIPAA Cyber Range • Authentic, turn-key, fun • Reports map to specific courses • Identify champions
- 33. 33 Questions?
Editor's Notes
- Organizations have become overly reliant on vulnerability scanning. Scanners are akin to motion sensors - great for low risk, but not great for higher risk areas. Scanners are notorious for generating false positives, indicating problems that either are non-existent or cause additional time spent on needless investigation. Utilization of scanners frequently fails to address each application’s unique code-, system-, business logic- and workflow- level vulnerabilities. More importantly, it provides little practical guidance on prioritizing threat remediation or creating a roadmap to guide enterprise software security posture improvements. We have 3 types of problems: Finding vulns Fixing vulns Defending vulnerable systems …. This is not how we solve the software security riddle
- ASSET RATING - Document critical software assets, prioritize business applications and rate them on a scale that makes sense for the situation/company SDLC GAP ANALYSIS - Augment internal and customer requirements with industry best practices and see potential gaps RISK DISCOVERY & ASSESSMENT - Perform a threat-based review of applications and/or systems-level technical specifications and attack vectors APPLICATION RE-ORDERING - After threat modeling, re-assess the risk ranking of your applications and put them into tiers based on standardized risk criteria Icons for use in internal pages SECURITY TEST CALIBRATION - Construct a security testing framework that ensures breadth and depth of testing is commensurate to application criticality
- Applications rely heavily on their environment in order to work properly. They depend on the OS to provide resources like memory and disk space; They rely on the file system to read and write data Tthey use structures such as the Windows Registry to store and retrieve information the list goes on and on. Like any input, if the software receives a value outside of its expected range, it can fail. Inducing failure scenarios can allow us to watch an application in its unintended environment and expose critical vulnerabilities. Asset Rating Example: You can base your asset rankings on Business Impact Analysis (BIAs) that may have already been performed, or base it on the sensitivity of data processed by these assets, the value to the business, or impact on operations - ie. what might be lost if the asset is compromised or if access is denied. Tip: A useful tool for this analysis is called Factor Analysis of Information Risk (FAIR). FAIR underlines that risk is an uncertain event and one should not focus on what is possible, but on how probable an event is likely to occur. This probabilistic approach is applied to every factor that is analyzed. The risk is the probability of a loss tied to an asset. Learn more about the FAIR Methodology to see if this tool makes sense for your analysis.
- or systems built internally, a SDLC gap analysis is critical. This can be as simple as a questionnaire, with results compared against an industry standard, for example, PCI SSF and the associated Secure Software Lifecycle (Secure SLC) Requirements. This will help quickly gather a sampling of your development team practices and determine where your biggest gaps are, benchmarking discrepancies in the development process based on product line, technology, locality, and other factors. The result should be both the gap report and creation of a secure development policy.
- Risk Discovery involves the review of application- or systems-level technical specifications in order to understand exactly how the technical system in question has been designed and deployed. To ensure that the risk implications of each application are correctly assessed, start by constructing a unified view of threats and risks at both business workflow and technical system levels. Different threat modeling techniques can be used to ensure a 360-degree view. One of the best is STRIDE, created and adopted by Microsoft in the early 2000s; however, you may find others like PASTA more to your liking. There are a myriad of great models covered here.
- Software risk assessment activities should include the review and/or development of: • Asset and data classification schemas • Security classification schema for applications which specifies classification criterion, e.g. type of data processed, internal vs. external, etc. • Tabletop exercises to discuss additional threat vectors • Current secure software development/SDLC security practices and controls • The software application portfolio risk rating framework that considers: – Business impacts – Security threats – Compliance and regulation mandates – Customer requirements – Operational safety and Cybersecurity risk
- Look at each business application and its environment to generate a business-level threat model and as many deep threat vectors as possible: • Identify and prioritize high-risk applications based on business impact, security threats, compliance mandates and operational risk. • Recommend security assessment activities based on application and data security risk. - Take a first pass at test recommendations. - They may range from a rapid fully- automated scan for lower risk applications to a deep manual inspection for applications that pose very high business risk. • Create a risk rating framework that will enable you to allocate security budget and resources to match the level of effort to the criticality of each application. Risk modeling, incorporating Secure Software Development Life Cycle (SSDLC) and other best practices drawn from such internationally-accepted standards as the NIST Cybersecurity Framework (CSF), ISO 2700x series, and PCI-SSF, helps ensure that application vulnerabilities are viewed in the broader risk context of business asset valuation, regulatory compliance, and operational efficiency.
- Threat modeling of the application workflow, coupled with attack modeling and design/code review of the application, traces all the ways that application end-users and administrators might accidentally or intentionally exploit faulty application control logic or coding errors. The insight gained from threat modeling may be used to determine the next steps for your application’s lifecycle. This may include: • Deeper or broader testing • Rebuilding • Replacing it with another application • Accepting the risks as-is • Deploying different/additional mitigation controls, or • Taking it out of service completely
- Regardless of the outcome, you will have better insight into: • Digital assets that are most at risk and require protection • The most likely threats to those at-risk assets • Specific malicious attacks that could be used to realize those threats • Design and deployment conditions under which attacks would be successful • Mitigations or additional testing that must be conducted to reduce the identified threats or prove/disprove their existence
- - Data classification reflects the level of impact to your organization if the data is compromised and includes factors such as compliance mandates, federal laws and internal standards - Application attack exposure is an important factor in the relative attack risk each application carries. Some applications have very little exposure, while others are exposed to a large number of users over the internet. Some are connected to other enterprise systems, databases or web services, while others are more isolated and harder to access
- • Data sensitivity. Does the application store, process, or transmit sensitive information such as intellectual property, financial records, privacy information, etc. The scale should reflect the degree to which the data handled is sensitive. • Lifespan. How long is the application expected to live? Statistically, the longer the life of an application, the more likely it is to be attacked and compromised. • Compliance. What legal, regulatory, or other compliance mandates is this business application expected to meet? More importantly, what is the risk implication should it be out of compliance? • Impact of Application Loss or Compromise. This is a measure of hurt, i.e., how painful it would be to the business or mission should this application be made unavailable for an extended period of time. • Customer/Internet Facing. This is a binary 0 or 1. Many view internet-facing applications as more risky than internal. In our view, because threats come from both inside and outside an organization, both scenarios carry risk. Figure 5 For each application, simply add the 5 numbers together to get a total ranging from 0 to 12. The resulting table looks something like this:
- The by-product(s) of utilizing the SToRM analysis above will ensure that technology and security teams are equipped with the necessary framework to implement repeatable software security and development best practices. The application portfolio risk assessment and classification can be leveraged to provide visibility into the state of development practices and application security across an organization’s business lines. Combined with asset and application classification, you can now identify and prioritize high-risk applications based on business impact, security threats, compliance mandates, and operational risk. The result is a risk rating framework that will allow for better resource allocation and identification of high-risk areas.
- The outcome of this gap analysis should contain a specific remediation roadmap, as mentioned above. However, the sequencing of new activities and tools needs to be considered carefully. Too often, organizations try to do too much too quickly, and efficiencies can grind to a halt. Consider training as a critical success factor. Introduction of new tools without training on the objective, activity, and benefit is going to be significantly less effective. This is analogous to handing a pneumatic jack hammer to an unskilled laborer who’s currently using a manual handpick. Maybe s/he could figure out how to use it; maybe they’ll use it wrong and do more damage than good; but most likely, they simply won’t bother to even try and will stick with what they know. When rolling out training, consider each person’s job function and the technology stack for which they need training. One size does not fit all when it comes to software security education. A Java developer needs very different training than a .NET developer, even though they both may be building web applications. An IT engineer tasked with protecting software in play will require different training than a software or DevOps engineer that focuses more on building security into the process.
- Almost every organization has some combination of home-grown applications, COTS (commercial off-the-shelf) applications, and outsourced/bespoke applications. Each one poses similar types of risks to your organization and each one should have some type of cybersecurity acceptance testing criteria based on your SDLC policy. Documentation of security standards and checklists for product development teams (regardless of where they reside, organizationally) is a byproduct of this exercise as well. Be sure to enforce them and review them regularly. These formal procedures and steps should be used to evaluate new and existing software applications against your customer, regulatory, and security standards.