Assessing System Risk the Smart Way
Download as PPTX, PDF0 likes116 views
Information systems in the digital age are complex and expansive, with attack vectors coming in from every angle. This makes analyzing risk challenging, but more critical than ever. There is a need to better understand the dynamics of modern IT systems, security controls that protect them, and best practices for adherence to today’s GRC requirements. These slides are from our webinar covering topics like: · Threats, vulnerabilities, weaknesses – why their difference matters · How vulnerability scanning can help (and hinder) your efforts · Security engineering and the system development lifecycle · High impact activities - application risk rating and threat modeling
Ad
More Related Content
What's hot (18)
Similar to Assessing System Risk the Smart Way (20)
![[Warsaw 26.06.2018] SDL Threat Modeling principles](https://cdn.slidesharecdn.com/ss_thumbnails/warsaw26-180628121942-thumbnail.jpg?width=560&fit=bounds)
Ad
More from Security Innovation (20)
Ad
Recently uploaded (20)
Assessing System Risk the Smart Way
- 1. Assessing IT System Risk the Smart Way
- 2. About Security Innovation • 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
- 3. A little about me… • CEO by day; engineer by trade (and heart) • Mechanical Engineer, Software Engineer • Distinguished Research Fellow, Ponemon Institute • Privacy by Design Ambassador, Canada • 2018 & 2019 Influencer Award, SC Magazine • In younger days, built non-lethal weapons systems for Federal Government
- 4. Agenda Threats, vulnerabilities, and weaknesses – oh my! • Vulnerability scanning: how it helps (and hinders) efforts • Security engineering and the SDLC • Application risk rating and threat modeling
- 5. Vernacular Calibration • Threat • Undesired event or potential occurrence • May or may not be malicious in nature • Might damage or compromise an asset • Vulnerability • Weakness in some system aspect or feature that makes an exploit possible • Can exist in network, application, infrastructure, 3rd-party, etc. • Attack/Exploit • An action taken against a weakness/vulnerability to realize a threat • Could be someone following through on a threat or exploiting a vulnerability • Countermeasure • Defenses that reduce probability or impacts of attacks • Improvements to system design, code, operational practices
- 6. Assessing Risk • Take into account threats, vulnerabilities, likelihood, and impact • Include external parties: • Service providers • Contractors • Individuals • Outsourcing entities • Public users • Conduct at: • Organization level • Business process level • Information system level • Any phase of the SDLC
- 7. Assessing Risk • Risk assessed at various steps in risk management framework • Categorization • Control selection • Control implementation • Control assessment • System authorization • Control monitoring • Risk assessments play an important role • In the control selection processes • During application of tailoring guidance • During vulnerability scanning process security control: defense tactic to protect individuals, operations, and assets
- 8. Agenda • Threats, vulnerabilities, and weaknesses – oh my! Vulnerability scanning: how it helps (and hinders) efforts • Security engineering and the SDLC • Application risk rating and threat modeling
- 9. Vulnerability Scanning • Scanning is just that: Scanning (it isn’t even testing) • Network infrastructure and endpoint scanning most common • Detection phase of “detect & respond” • Many tools for this, e.g., AlienVault • Software requires additional approaches • Static analysis (source code) • Dynamic analysis (compiled/deployed app) • Binary analysis (reverse engineering) • Complement with risk-based approaches • Threat modeling • Application risk rating • Attack surface reduction
- 10. What to Scan for • Common vulnerable areas: • Patch levels • Open ports • Active protocols & services • Improper configurations • Incorrectly operating flow control • OWASP Top 10 (for Web, Mobile, IoT) • Common naming/scoring conventions: • CVE • OVAL • CVSS Key question: What services/features should not be accessible to users or other devices?
- 11. • Adopt when you have baseline skills to: • Interpret false positives • Fix problems found • Augment with manual test efforts • Complement with sound process & training • “When?” is just as important as “Which?” • Tools don’t make your organization more mature • Ensure tool matches your expected operational environment • Can’t validate a stop light controller as if it’s a web application DAST and SAST Tools
- 12. Polling Question • Which of the following do you use (check all that apply): • Network vulnerability scanning • Endpoint detection and response (EDR) scanning • DAST scanning for web applications • SAST scanning for software applications
- 13. Risk Assessment Program Goals • Improve Vulnerability Management • Regular, iterative testing ensures continually-improving test results • Reduce vulnerabilities over time by learning from past mistakes • Focus on the find AND fix • Optimize Frequency and Depth of Testing • Let tools and humans do what they do best • Match level of testing and analysis to application criticality • Optimize Costs • Predictability • Investment matched to level of risk
- 14. Agenda • Threats, vulnerabilities, and weaknesses – oh my! • Vulnerability scanning: how it helps (and hinders) efforts Security engineering and the SDLC • Application risk rating and threat modeling
- 15. System Development Lifecycle (SDLC) • System Development Life Cycle (SDLC): • Development • Implementation • Operation • Applying security controls w/in SDLC requires basic understanding of: • Information security threats • Vulnerabilities • Potential adverse impacts • Risks to critical missions/business functions
- 16. SDLC Skills • Individuals that design, code, test, and operate IT systems should understand security • Business Analysts • Developers • Software Engineers • Information Security • System Architects • Network Engineers • IT Operations • Database Administrators • Security awareness and training ensures personnel have appropriate expertise to conduct assigned activities • With line between build and maintain forever blurred, shared knowledge of attack and defend within team is critical
- 17. Security Requirements • Define early in SDLC • Support mission/business process • Integrate into security architecture • Use cases & Abuse cases • Align with risk management goals and information security strategies
- 18. Security Engineering Principles • Develop layered protections to reduce risk • Minimize attack surface • Fail securely • Define physical/logical security boundaries • Secure default settings and access • Train IT system team members on security • By job function • By technology stack • Tailor security controls to business needs • Least privilege • Perform Threat Modeling
- 19. System Developers • Follow a documented development process that • Explicitly addresses security requirements • Identifies standards & tools used in development • Documents specific tool options and configurations • Documents, manages, and ensures integrity of changes • Reviews the development process, standards, tools, and options/configurations regularly
- 20. Security Testing and Evaluation • Validates that required security controls implemented correctly • Operates as intended • Enforces the desired security policy • Meets established security requirements • Security properties may be affected by: • Interconnection of system components • Changes to system components • Previously implemented security controls.
- 21. Development Process, Standards, & Tools • Maintaining the integrity of changes to tools and processes includes: • Supply chain risk mitigation • 3rd-party vulnerability assessments • Acceptance testing criteria in SLAs • Robust configuration control • Tracking of authorized changes • Logging and Monitoring • Anti-tampering measures • Logical and physical • Prevention of unauthorized changes • Sign-off procedures
- 22. Agenda • Threats, vulnerabilities, and weaknesses – oh my! • Vulnerability scanning: how it helps (and hinders) efforts • Security engineering and the SDLC Application risk rating and threat modeling
- 23. Enterprise Application Risk Rating • Helps ensure • Assessment and mitigation activities are done cost effectively • Prioritization is based on real business risk • The business doesn't get distracted by minor risks while ignoring more serious risks that are less well understood • Inappropriate security assessments are costly • Deep inspection on all applications is neither feasible nor necessary • Running just an automated scan on critical application will lead to trouble • Allows you to understand risk-based options • Remove, replace, take off-line, or implement compensating controls Business Criticality is driving factor when determining which applications to secure and level of regular assessment needed
- 24. Risk Rating Framework • Risk = Likelihood * Impact • Remember: threats can be inherited from dependencies and connectivity • Attackers leverage non-critical apps to get to critical apps • Identify and prioritize application risk based on • Business impact: data criticality, compliance mandates, operational risk • Security threats: attack surface, exposure (e.g. internet vs. intranet) • There is no standard formula • Risk tolerance and data classification are contextual to each organization • Make sure risk-rating framework is: • Transparent so decisions and calculations can be easily explained • Adaptable so each group can apply unique drivers, goals, resources • Practical so you end up with something that works
- 25. Risk Rating Tiers • Tier 1 (critical) application • Highly sensitive data and/or compliance requirements • Internet facing • Business critical functionality • Long lifespan • Tier 2 (medium risk) application • Medium sensitivity data, no compliance requirements • Intranet facing • Business important functionality • Mid-to-long lifespan • Tier 3 (low risk) application • Low sensitivity data • Short lifespan with low importance functionality • No authentication or authorization required Tier 1 Tier 2 Tier 3
- 26. Risk Rating in Practice Application is an operational e-commerce application. It was built by a 3rd party. Data has been collected and stored in an encrypted cloud database. Data collected is sensitive. Choose scale, e.g., 0-10 (low to high) and 4 rating criteria, e.g., 0-3 x 3 and 0-1 x 1 • Data Sensitivity (3) – Full names, addresses, account numbers, credit card information • Lifespan (3) – This application does not have an EOL set • Compliance (2) – PCI, PII, GDPR • Customer or Internet Facing (1) – This application is hosted on a dedicated Virtual Server within the DMZ, is Internet-facing, and accesses a database in a co-located data center Risk Rating 9/10 Tier 1
- 27. Risk Rating in Practice Application is a cash back marketing website. Data collected consists of only order number and product serial. Data collected is not sensitive. Choose scale, e.g., 0-10 (low to high) and 4 rating criteria, e.g., 0-3 x 3 and 0-1 x 1 • Data Sensitivity (1) – No names, addresses, account numbers, or credit card information • Lifespan (1) – This application will only exist for a one month promotion • Compliance (0) – no PCI or PII data collected • Customer or Internet Facing (1) – This application is hosted on a shared cloud-based web server in a virtual data center with other LOB applications Risk Rating 3/10 Tier 3
- 28. Resulting Risk-Based Test Matrix Threat Rating Static Analysis (Source Code) Dynamic Analysis (Web App Scanning) Manual (Penetration Testing) Threat Modeling Complete Frequency Complete Frequency Complete Frequency Complete Frequency Tier 1 (Critical) Required Major Code Changes Required Major Code Changes Required Per-Milestone Required Per-Release Tier 2 (High) Suggested Monthly Required Quarterly Required Per-Release Suggested Per-Release Tier 3 (Low) Optional Quarterly Required Annually Optional As needed Optional As needed
- 29. Polling Question • Do you currently use a risk-based testing matrix similar to what was shown on the last slide? • Yes • No • I was sleeping and missed it
- 30. Threat Modeling –Simplified Identify/quantify weaknesses; devise defenses • Sound familiar? • Most people threat model every day but don’t realize it • If I asked you to threat model my house, you could; even if you have never been Courtesy: Sean Gallagher “Nearly 50% of security flaws will be discovered from Threat Modeling because it finds different threats than those found through code review” -Michael Howard, Security Program Manager, Microsoft
- 31. Threat Profiles are Never the Same Is this a threat in Nebraska?
- 32. Threat Mitigation Vulnerability Attacker Threat Modeling Vulnerabilities are unmitigated threats Here’s our opportunity! • Threats are not vulnerabilities; they are attack vectors and live forever • Should include use cases, threat agents, attack vectors, compensating controls and design patterns • If done right and at every phase, provides more leverage than any other security activity • 12 Methods: https://insights.sei.cmu.edu/sei_blog/2018/12/threat-modeling-12-available-methods.html
- 33. Polling Question • Do you have an active Threat Modeling practice at your organization? • Yes • No
- 34. Summary • Learn and adopt a simple RMF, e.g., • https://csrc.nist.gov/projects/risk-management/risk-management-framework-(RMF)-Overview • Use vulnerability scanning tools, BUT • Do so after role- and technology-based training • Be sure to configure properly and expect many false positives • Consider risk-based application security testing framework • Data and application risk categorization • Calibrate depth and frequency of testing to risk tiers • Deploy threat modeling for streamline assessments
- 35. Questions?