SHIFTLEFT Cyber Security Modernization Naor Penso Cyber Security

SHIFT-LEFT Cyber Security Modernization Naor Penso Cyber Security Evangelist www. naorpenso. com

Agenda Chapter 1 Shift Left Chapter 2 Securing the Business Chapter 3 Getting Practical Chapter 4 Security Overlays Security? Agility? Defining requirements that we Disassembling business and Foundational security measures We are on a collision course. can all understand (the business security requirements to controls crossing the cloud too!)

CHAPTER 1 Shift Left

What is “Shift Left” In the past, where a majority of software teams approached work with a waterfall model, the workflow looked something like this example from Winston Royce's "Managing The Development of Large Software Systems", first published in 1976.

What is “Shift Left” In an Agile world, teams are being asked to move faster — reducing the length of time to delivery while still continuing to improve the quality of each release. Shift left refers to the incorporation of testing at early stages of development. Shift left doesn't exactly move testing closer to the beginning of a release cycle. It sprinkles it over each step and each iteration.

“Shift Left” and Security The problem security Security wants MAXIMUM security Business wants MAXIMUM agility Agility ≠ MAXIMUM security

“Shift Left” and Security The real problem Business is located HERE Agility Security is located HERE

The customer Business target setting “Shift Left” and Security Requirement Gathering This is how projects look like for most organizations Service / Solution Discovery

The customer Testing / Validation “Shift Left” and Security Procurement This is how projects look like for most organizations Hey, hey, HEY!!!! Deployment

The customer Testing / Validation “Shift Left” and Security Procurement This is how projects look like for most organizations Security

“Shift Left” & Security Moving security “upstream” (left) in the process to embed security effectively and with minimal resistance Shift left doesn't exactly move testing closer to the beginning of a release cycle. It sprinkles it over each step and each iteration.

The customer Business target setting Well, there are several risks to take into consideration “Shift Left” and Security How projects should look like Make sense Requirement Gathering We think that encrypting this very sensitive data is crucial Correct! Service / Solution Discovery Wow, this solution doesn’t encrypt data? You're out of the game….

The customer Testing / Validation We found some vulnerabilities! “Shift Left” and Security This is how projects look like for most organizations What can we do? Let’s make sure they commit to fix before we buy. Procurement Make sure you fix this and that. Also these are our security contractual requirements Ok… Deployment The system is secure! And were on schedule

BUSINESS TARGET SETTING REQUIREMENTS GATHERING SERVICE / SOLUTION DISCOVERY Best phase to identify potential risks, set Best phase to define the security Best phase for helping steer the evaluations expectations with the business and define requirements for the project as a part of the towards a more secure solution the key security objectives for the project business requirements and “No-Go’s” TESTING / VALIDATION PROCUREMENT DEPLOYMENT Best phase to proof the security of the Best phase to inject security constrains / Best phase to implement the required security solution, identify & mitigate gaps and test guidelines into the contract with the vendor controls and define the action plans for different security overlays (e. g. SIEM integration) and mandate control implementation scenarios (e. g. attack on the system, data leakage)

CHAPTER 2 Securing the business

A GOOD SECURITY ARCHITECT BAD FW IPS DLP IDM SIEM VM WAF DBF ERM EDR PIM RM UBA NBA SSO

A GOOD SECURITY ARCHITECT 1. Understands the business requirements & targets 2. Can define business enabling security requirements 3. Understands risks and what’s important 4. Can articulate why something needs to be done (not just what) 5. Knows security

2 WAYS TO REPRESENT SECURITY Both ways are systematic, and can be reused for different projects USER STORIES (SECURITY) SECURITY BUSINESS REQUIREMENTS User stories are a known Agile method of describing Security business requirement is not told as a story, but does encompass the required features in a business way. Instead of developing a needed framework to make the business understand the security need. button without understanding why, its always tied with a Example: “user ask”, in example: As a financial analyst I would like a To protect the system from a breach, we are required to implement access controls. report for last month’s profit and loss. User stories are normally done when SCRUM agile method Security business requirements can (and will) be broken-down later on to is used, they are not mandatory for every project. measurable controls. Having said that, incompliance with a measurable controls will cause the business requirement to fail, making it easier for the business to understand.

SECURITY USER STORY someone do something I WOULD LIKE THE ABILITY TO ___________ AS A ______ Security Architect Prevent unauthorized access Security Engineer Identify system breach Security Analyst Validate compliance with laws and regulations Compliance Manager Secure data assets Risk Manager Enable secure sharing of data User List Activity List

SECURITY BUSINESS REQUIREMENT something WE ARE REQUIRED TO __________ do something TO PROTECT THE SYSTEM FROM ____ Data leakage (C) Prevent unauthorized access Unauthorized data manipulation (I) Identify system breach Defacement (A) Validate compliance with laws and regulations User Mistake (I) Secure data assets Unauthorized Access (C) Enable secure sharing of data Threats Activity List

SECURITY BUSINESS REQUIREMENT something TO PROTECT THE ORG FROM _____ do something WE ARE REQUIRED TO __________ Lawsuit Manage changes in the system Contractual Breach Identify system breach Incompliance with PCI-DSS Validate coherence with ISO 27001 Incompliance with SOX Validate the data is encrypted Sign EU privacy protection act sheet (e. g. Safe-Harbor / Privacy Shield) Threats Activity List

CHAPTER 3 Getting Practical

PHASE 1 – BIG ROCKS TO CONSIDER Based on NIST 800 -53 Rev. 4 & NIST 800 -144 1. Compliance 2. Roles and Responsibilities 3. Governance 4. Security 5. Data

TRUST Compliance Roles and Responsibilities Governance Security Data TRUST High Trust OK OK OK Maybe Medium Trust OK OK Maybe Low Trust OK Maybe No No Not Sensitive Low Sensitivity Medium Sensitivity High Sensitivity DATA

15% COMPANY • • MEASURING TRUST Company Size Revenues Operational Years Other Customers 30% COMPLIANCE • • Certifications External Audits Contractual commitments Laws & Regulations* 15% ROLES & RESPONSIBILITIES • Who does what? 40% SECURITY & GOVERNANCE • Is it secure? • Governance Model • Ability to govern

PHASE 2 – CONTROL EXTRACTION 1 2 3 BUSINESS REQUIREMENTS SECURITY CONTROLS Collected at the beginning of the Business oriented requirements that The technical manifestation of the project, includes the “Why” and are consensually agreed with the security requirements the goals of the project customer

PHASE 2 – CONTROL EXTRACTION 2 3 SECURITY REQUIREMENT SECURITY CONTROLS “To protect the system from data leakage, we are required to prevent unauthorized access” • • • Ability to manage users Existence of role based access control Ability to integrate via SSO (e. g. SAML) Ability to block access from unauthorized locations Ability to recertify access permissions to the system

PHASE 2 – CONTROL EXTRACTION How it will look in an excel file? What are we protecting? From what we are protecting? What are we required to do? How can we achieve it? Is it mandatory? Incompliance Severity The system Data Leakage Prevent unauthorized access Ability to manage users Yes Critical The system Data Leakage Prevent unauthorized access Existence of role based access control Yes Critical The system Data Leakage Prevent unauthorized access Ability to integrate via SSO (e. g. SAML) No Medium Prevent unauthorized access Ability to block access from unauthorized locations No High Prevent unauthorized access Ability to recertify access permissions to the system No Low The system Data Leakage Advantages: For those that need more: • Ability to identify multiple deficiencies, unachieved targets • You can add mandatory flag based on data sensitivity • Ability to articulate what is the business reasoning for a control • You can add cloud level applicability (Saa. S / Paa. S / Iaa. S) • Demonstrate flexibility • You can add who is the owner (yourself / project owner / solution provider) • You can deduct what requirements should be placed in the contract • You can add pass/fail and use this excel as the leading document

PHASE 2 – CONTROL EXTRACTION For those crazy people Data sensitivity Cloud Type Public LBI MBI HBI Iaa. S Paa. S Saa. S x x x ~ Usage / Access / User Type All Access Anonymous User Administrative Application Machine x x x

PHASE 2 – CRITICAL CONTROLS / GROUPS Specific to the cloud 1. Contractual Requirements 1. SLA 2. Liability 3. Access to data 4. Ownership of data 5. Compliance & Governance 6. Security Demands (e. g. Penetration Testing, Data Encryption) 7. Termination 8. Confidentiality & Third party access

PHASE 2 – CRITICAL CONTROLS / GROUPS Specific to the cloud 1. Iaa. S Controls 1. Encryption / Key Management 2. Administration environment security 3. Function Hardening 4. Least Privileges 5. IPSEC / Network Overlay (very depending on need) 6. Service Bureau

PHASE 2 – CRITICAL CONTROLS / GROUPS Specific to the cloud 1. Paa. S Controls 1. Encryption / Key Management 2. Administration environment security 3. Application Security 4. Least Privileges 5. API Management 6. API / Access restrictions 7. Image verification, vulnerability scanning (for Containers)

PHASE 2 – CRITICAL CONTROLS / GROUPS Specific to the cloud 1. Saa. S Controls 1. Access Control 2. Monitoring 3. Data Leak Prevention 4. Least Privileges 5. User Behavioral Analytics 6. API Management 7. API / Access restrictions 8. Third Party Software restrictions

CHAPTER 4 Security Overlays

MONITORING & FORENSICS IDENTITY AND ACCESS MANAGEMENT DATA LEAK PREVENTION RISK MANAGEMENT BEHAVIORAL ANALYTICS GOVERNANCE PLAN

Thank you for your time… - NAOR PENSO -