Regulatory compliance mandates have historically focused on IT & endpoint security as the primary means to protect data. However, as our digital economy has increasingly become software dependent, standards bodies have dutifully added requirements as they relate to development and deployment practices. Enterprise applications and cloud-based services constantly store and transmit data; yet, they are often difficult to understand and assess for compliance. This webcast will present a practical approach towards mapping application security practices to common compliance frameworks. It will discuss how to define and enact a secure, repeatable software development lifecycle (SDLC) and highlight activities that can be leveraged across multiple compliance controls. Topics include: * Consolidating security and compliance controls * Creating application security standards for development and operations teams * Identifying and remediating gaps between current practices and industry accepted "best practices”

1. 1

2. 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. 3
About Me
• 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

4. 4
Agenda
 Consolidating security and compliance controls
 Creating AppSec standards for development & operations teams
 Plugging gaps between current and industry best practices

5. 55
Consolidating Security & Compliance Controls

6. 6
Executive Management
GRC & Security Teams
Functional Practitioners
Corporate Application Compliance Framework
aligning development and IT with management policies

7. 7
AppSec Requirements are Emerging
• Why? They store and process the most data
• Regulations historically focused on network security, but now seeing:
• FISMA & NIST - require organizations to integrate security assessments into SDLC
• PCI-DSS - “secure coding standards”; “..prevent vulnerabilities such as injection flaws”
• SEC - Evaluate security risks to determine if disclosure is required
• Dozens of others
• Requirements can be general and implications non-obvious
• “Develop according to industry best practices”
• uh, where can I find those?
• “Protected information” should not be improperly altered or destroyed
• Huh???

8. 8
Software Has Full Control of Your Data
Firewall Hardened OS
Web Server
App Server
Firewall
Databases
LegacySystems
WebServices
Directories
HumanResrcs
Billing
Custom Developed
Application Code
APPLICATION
ATTACK
You can’t use network layer protection (firewall, TLS, IDS, hardening) to stop or detect application layer attacks
NetworkLayerApplicationLayer
Your security “perimeter” has huge holes at the application layer
Insecure Code is Insecure Processing!

9. 9
It’s All About the Data
• Understand what data you are collecting
• How important is it to you or the individual?
• What bad things can happen if you lose the data? Threat model!
• Understand what apps are processing the data
• Ones you own and those you don’t, e.g., Cloud services
• Data protection by design and default
• Are you doing what you can to keep unauthorized folks out
• Implement measures early in design
• Process with highest degree of privacy and security
• Data management
• How long shall we retain? Is it necessary?

10. 1010
CIA and Its Concepts – in Every Standard
Confidentiality
Only authorized individuals or processing systems can
access and view the data. Hide data from anyone
else.
Integrity
Insure that data is accurate and original. Data can be
altered by the individuals or processing systems only
with appropriate authorization.
Availability
Information is readily accessible to the authorized
individuals or processing system at all times.

11. 11
1
What is “the Processing of Data”
“Collection, recording, organization, structuring,
storage, adaptation or alteration, retrieval,
consultation, use, disclosure by transmission,
dissemination or otherwise making available,
alignment or combination, restriction, erasure or
destruction”1
Basically everything you can ever do with
data means processing!

12. 1212
How is Data Processed In Your Organization?

13. 1313
Classify Data and Apps That Process It
• How important is the data to you?
• How important is the data to the individual the data belongs to?
• What bad things, if any, can happen if you lose the data?
• To you
• To the individual
• To any other entity
• Look beyond the obvious
• Risk-Rank your applications to match your level of security to the risk
• We offer a separate 45-min webcast on how to do this

14. 14
Safe Harbor from Culpability: Best Practices
• Many factors will determine the penalty (if any)
• Biggest factor: “Did you try to protect the data?”
• Known deficiency of IT systems
• How long was the risk present?
• Were tests carried out to detect or prevent such an attack?
• How many customers had their data stolen/disclosed?
• What type of data was affected – did it include sensitive data?
• Was the data encrypted, and if so, using what method(s)?
• “Best Practices” = due diligence
• Showing/documenting industry best practices will help
• OWASP Top Ten, training, etc

15. 1515
You Can’t Secure Everything – So Don’t Try
• All compliance mandates push for a risk-based approach
• Understand the overall business risk profile
• Software will never be 100% secure – it would be too costly, and simply won’t
provide any functionality of value to the user
• Don’t just think about keeping hackers out, but minimizing potential damage if
they get in
• Threat Modeling and Attack Surface Reduction can help protect against known
threats and unknown risks/vulnerabilities

16. 16
Polling Question:
• Do your developers understand what specific activities need to be
conducted for compliance?
• Yes, definitely
• Some, but not all
• No, probably not
• Unsure

17. 1717
Creating AppSec Standards

18. 18
Mapping OWASP Top Ten to PCI DSS 6.5.2
OWASP Top 10 – 2017
The Top 10 Most Critical Web Application Security Risks
A1 - Injection
A2 - Broken Authentication
A3 - Sensitive Data Exposure
A4 - XML External Entities (XXE)
A5 - Broken Access Control
A6 - Security Misconfiguration
A7 - Cross-Site Scripting (XSS)
A8 - Insecure Deserialization
A9 - Use of Components with Known Vulnerabilities
A10 - Mitigating Insufficient Logging & Monitoring Vulnerabilities

19. 19
Selected coding practices that contribute to compliance
High-Level
Requirement
Standards
(Partial List)
Selected Coding Practices
Confidentiality SOX, PCI DSS, HIPAA, ISO
27002, HIPAA, GLBA, FFIEC,
Basel l I, CA SB 1386, FIPS
199, NIST SP 800-30/ 800-
53/800-64
Appropriate use of strong encryption for data in databases.
Encrypting confidential data in memory. No custom or untrusted encryption routines.
Encrypting data in motion, especially for wireless transmissions.
Masking confidential data that needs to be viewed in part
Data integrity SOX, PCI DSS, ISO 27002,
HIPAA, GLBA, FIPS 199,
NIST SP 800-30/ 800-53/800-
64
Robust integrity checks to prevent tampering with data.
Input validation and comprehensive error handling to prevent injection attacks, privilege escalation, and
other hacking techniques.
Output encoding. Use of least privileges.
Hashing for confidential data that needs to be validated (e.g. passwords).
Authentication
and access
control
SOX, PCI DSS, ISO 27002,
HIPAA, II, NIST SP
800-30/ 800-53/800-64
Support for strong passwords & two-factor authentication where appropriate.
Role-based access control and revocation of rights, with clear roles mapped to permissions.
Locked down file access and database roles. No guest accounts.
Passwords and encryption keys encrypted before storage and transmission.
Logging and
auditing
SOX, PCI DSS, ISO 27002,
HIPAA, SB 1386, NIST SP
800-30/ 800-53/800-64
Detailed audit trails of users accessing data and resources.
Detailed logging of systems that process sensitive data, including shutdowns, restarts and unusual
events. No confidential data exposed in logs.
Event logs and audit trails available only to system admins and protected from unauthorized
modifications.
Availability SOX, ISO 27002, HIPAA, II
FIPS 199, NIST SP 800-
30/ 800-53/800-64
Code reliability. Failover and redundancy built into applications.
Applications resistant to denial of service attacks.
Clean up of confidential data in memory and in file systems during failures and shutdowns.
Change
management
SOX, BASEL II, NIST SP
800-53/ 800-64
Source control. Logging of application changes.
Application change logs accessible only to privileged users and resistant to tampering.

20. 20
• OWASP
• Maps to and referenced in many industry and regulatory compliance standards and frameworks
• U.S. FTC and DISA, PCI-DSS
• Used by many companies
• NSA: in their developer guidance on web application security
• Oracle: for developer awareness
• Web and code vulnerability scanners maps findings to OWASP Top 10
• CWE: most dangerous software weaknesses
• The CERT secure coding standards
• The Microsoft SDL (Secure Development Lifecycle)
Aligning Development Activities with Compliance:
OWASP and Other Coding Standards

21. 2121
Data Risk – Design Issues in Applications
• Improperly implementing access or authentication
controls
• Trusting client input for business logic decisions
• Not hashing and salting passwords
• Not encrypting or not properly encrypting data
• Insecure integration with other components
• Using components with known vulnerabilities
• Making assumptions about user input that are not
validated

22. 2222
Data Risk – Business Logic Issues Are Important
• These are not flaws in code or code implementation
• Flaws in logic the code implements that allow attackers
to perform malicious actions
• Not validating a phone number before allowing it to be
ported
• Not checking a financial counterparty blacklist (sanctions)
before sending payment
• Not allowing negative prices in shopping cart 
• Business logic flaws can be implementation of
insecure or incomplete business requirements
• Define abuse cases to help
• Define what the application is supposed to do,
and those actions it should definitely NOT
be allowed to do

23. 2323
Application Security Frameworks / Maturity Models
OWASP OpenSAMM PCI Software Security Framework
https://www.opensamm.org/ https://www.pcisecuritystandards.org/documents/PCI-Secure-SLC-Standard-v1_0.pdf

24. 2424
Key Activities
• Governance
• Policies and Executive Sponsorship
• Use a risk-based approach
• Know your data
• Minimize attack surface
• Education and Guidance
• Secure Development
• Create Threat Models
• Form Clear Security Requirements
• Apply Security Design Guidelines
Security Verification
• Conduct Security Architecture and
Design Reviews
• Perform Assessments: Security Code
Reviews & Testing
• Conduct Security Deployment Reviews
• Red Teaming

25. 2525
• Without Executive Sponsorship any AppSec program is shaky at best
• What good is a risk-assessment if wavers are granted for everything?
• Compliance drivers can be used to get buy-in
• Without Security Policies many efforts are wasted
• What good is a scanning tool if it’s use is not required
• Questions to ask yourself:
• Do you have corporate security and compliance policies?
• How is the development team made aware of security policies?
• How does the development team access security policies?
Security Policies and Executive Buy-In

26. 26
Polling Question:
• Which activity do you feel reduces the most application risk?
• Gathering security requirements
• Design reviews
• Security code review
• Penetration testing
• Threat modeling
• Attack surface reduction
• Deployment review

27. 2727
Plugging Gaps

28. 28
Security Activities Can Be Easily Layered Into Existing SDLC
• As you are gathering functional
requirements, gather security ones
• As you are choosing technologies and
components during design, investigate
the security of each
• As you write code to store and transmit
data, consider if it’s being done safely
• As you are testing for functional use
cases, add security abuse cases

29. 29
DevOps – Same Music, Different Dance Moves
• Integrate security at each step
• Automate where you can
Still need documented steps and standards to follow along properly

30. 30
SDLC Process Assessment – Graphical View

31. 31
Determine Security Process Requirements
Activity Matrix
Product A Product B Product C
Define Security Objectives X X
Apply Security Design Guidelines X X
Threat Model X X
Security Architecture and Design Review X X
Apply Security Implementation Guidelines X
Security Code Review X X X
Security Penetration Testing X X X
Apply Security Deployment Guidelines X
Security Deployment Review X
3rd party Security Penetration Test X X X
Security Incident Response Plan X X X

32. 3232
Category Guidelines
Input / Data Validation Do not trust input; consider centralized input validation. Do not rely on client-side validation. Be careful with canonicalization
issues. Constrain, reject, and sanitize input. Validate for type, length, format, and range.
Authentication Use strong passwords. Support password expiration periods and account disablement. Do not store credentials (use one-way
hashes with salt). Encrypt communication channels to protect authentication tokens.
Authorization Use least privileged accounts. Consider authorization granularity. Enforce separation of privileges. Restrict user access to
system-level resources.
Configuration Management Use least privileged process and service accounts. Do not store credentials in clear text. Use strong authentication and
authorization on administration interfaces. Do not use the Local Security Authority (LSA). Secure the communication channel for
remote administration.
Sensitive Data Avoid storing secrets. Encrypt sensitive data over the wire. Secure the communication channel. Provide strong access controls
for sensitive data stores.
Cryptography Do not develop your own. Use proven and tested platform features. Keep unencrypted data close to the algorithm. Use the right
algorithm and key size. Avoid key management (use DPAPI). Cycle your keys periodically. Store keys in a restricted location.
Exception Management Use structured exception handling. Do not reveal sensitive application implementation details. Do not log private data such as
passwords. Consider a centralized exception management framework.
Auditing and Logging Identify malicious behavior. Know what good traffic looks like. Audit and log activity through all of the application tiers. Secure
access to log files. Back up and regularly analyze log files.
Design Guidelines – Best Practices

33. 33
Determine Security Training Requirements
Product A Product B Product C
How to Define Security Objectives PM, SC PM, SC
Application Security Fundamentals E E
Attacker Techniques Exposed O O O
Architecting Secure Solutions O O O
Security Architecture and Design Review A, SC A, SC A, SC
Threat Modeling A, D, SC A, D, SC
Creating Secure Code Java D
Creating Secure C++ Code D D
Conducting a Security Code Review D, SC D, SC D, SC
Classes of Security Defects D, T D, T D, T
Buffer Overflows D
Security Testing T T O

34. 3434
Education & Guidance
• Train your team to understand the implications of insecure
applications to prevent code- and business- logic mistakes
• InfoSec & GRC
• Executive
• Technical/Practitioner (Dev, IT, Audit)
• Arm your personnel with knowledge and resources to design, develop,
and deploy software securely
• Train staff to “think like an attacker”
• Reducing attack vectors is everyone’s responsibility
• Hands on simulations are most effective at fostering attitude

35. 35
The Microsoft SDL: Reduction in Vulnerabilities
119
66
400
242
157
Windows® XP Windows
Vista®
OS I OS II OS III
Total Vulnerabilities Disclosed 12
Months After Release
34
3
187
SQL Server® 2000 SQL Server 2005 Competing commercial DB
Total Vulnerabilities Disclosed 36
Months After Release
Before SDL After SDL
45% reduction in Vulnerabilities
Before SDL After SDL
91% reduction in Vulnerabilities
Consistent use of security practices during all phases of
development facilitates compliance and reduces vulnerabilities

36. 36
Final Polling Question
• Do you currently conduct regular software security training?
• Yes
• No
• No, but we plan to soon

37. 37
Conclusion
• Most regulations, frameworks, and compliance mandates:
• Say the same thing: protect your data
• Revolve around the same key AppSec concepts
• There are known and generally accepted best practices for safe harbor:
• OWASP, Microsoft SDLC, CWE, NIST, CERT
• Rolling out a repeatable SDLC that integrates key security and compliance activities:
• Ensures future requirements will have little impact on existing efforts
• Allows you to maintain a “big picture” view to software development and IT teams
• Follow the data
• Threat Modeling and application risk rating are natural forcing functions

38. 38
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

39. 39
www.securityinnovation.com
Thank You!Thank You!