Common Challenges to Secure Software Development Integrity Checks and Security Assessments Internal and 3rd Party Security Considerations

1. Reduce 3 Party Developer
Risks

2. Agenda
• Common Challenges to Secure Software Development
• Integrity Checks and Security Assessments
• Internal and 3rd Party Security Considerations

3. Understanding Root Cause of Vulnerabilities
• Failure to set requirements and standards
• Not enough training and education
• Lack of process
• Vulnerabilities are unintended functionality

4. Security vs. Software Quality
When you think of
3rd party language
for functionality
requirements, think
similarly for security
requirements

5. The Organizational Disconnect
• IT/GRC/InfoSec historically focused on network/endpoint security
*Developers and SDLC are now “in scope”
• Tools are a typical first step
*Both have different perspective on what policies and procedures are in place
• How did we handle performance, reliability?
*Security needs to be a standard part of the process

6. Language, Platform & Framework
Nuances
• Security policies are not enough
o Follow through with architecture and development standards
o Must explain “how” and “why,” not just “what”
o Must tie to specific roles and technologies
• Each language has unique idiosyncrasies and syntax issues:
o C++
o Java and .NET
o Scripting languages
• Each platform is unique:
o Mobile
o Cloud & Web
o Embedded

7. The Pitfalls of Automation
• First instinct is “what tool can we buy”?
• It can do a lot of heavy lifting faster than humans; but they….
o Only find KNOWN vulnerabilities/patterns and can miss important issues
o Don't teach you how to fix vulnerabilities or prevent them in the future
o Useful as part of an assessment program, but shouldn’t be your sole solution
• Analyzing results is time consuming and requires skill
• Results:
o Tools often become shelf-ware
o Dev team pushes back against vulnerability management in the SDLC

8. • Network boundary plays key role in “defense-in-depth”, but….
o Misses the majority of security vulnerabilities
o Ineffective when applications are internet facing
o Attackers can/will break through
• With Internet, applications become the perimeter
• We still invest exponentially more in network defenses
Security is Ultimately a Software Problem
* source: Gartner and NIST
70-92%
of vulnerabilities exist in the application, not network layer*

9. …. and a Human Problem
• Vulnerabilities are frequently the result of a failure in
the engineering process
• Developers have an implicit trust in the user
o Often think of functionality (practical) rather than security
o Not common to consider abuse cases
• Education tailored to each environment isn’t required
o Particularly in requirements and design phase where few tools
available
o Wide range of technologies and platforms is overwhelming

10. Agenda
• Common Challenges to Secure Software Development
• Integrity Checks and Security Assessments
• Internal and 3rd Party Security Considerations

11. Integrity Checks
• Perform security assessments
o Design reviews, code reviews, penetration tests at key validation points
• Address security beyond the traditional “testing” phase
• Security assessment = more than penetration testing the
binary:
o Validating the design and the architecture before coding begins
o Developing a threat model that guides design, coding and test efforts
o Using tools while developers are coding to find common security defects
o Verifying the security and configuration of the deployment environment

12. Assessment Activities Work Together
• Design review
o Sets the rest of the team up for success and finds problems that are the
costly to fix later in the cycle
• Threat Modeling
o Ensures key threats are considered during design, coding and testing
• Code Review
o One of the highest impact activities, but doesn’t consider the
as-deployed state

13. …Continued
• Manual penetration testing
o Requires deep knowledge of application and technologies in the
environment
• Scanning tools
o Provide broad coverage to augment these activities

14. State of Application Security Assessment
Conventional approaches to application security are not risk-based
• Over-reliance on automated vulnerability scanning
• Random efforts to find a needle in a haystack
• Fails to address each application’s unique code-, system- and workflow-level
vulnerabilities
• Little practical guidance on prioritizing defect remediation
• Find & Fix “hamster wheel” leads to frustration and stagnation
• Many flaws are caused by environment interaction and only discoverable after
analyzing application in production

15. …Continued
An effective security assessment program
• Uses threat modeling to focus efforts on highest risk first
• Is committed to finding problems at each phase of development
• Aligns breadth and depth of analysis to application complexity and criticality
• Let’s humans and tools do what they each do best
• Leverages assessment findings to identify root causes and address process and
skills gaps

16. It’s Called “Verification Phase” for a
Reason
• Security testing should be like the net under a tightrope
o Not the only time when security problems are found
• Why do we often find so many vulnerabilities in testing?
o If architecture and development standards are followed, vulnerabilities will be
minimized
o If assessment activities occur consistently, vulnerabilities will be found early
• Penetration testing becomes the last-best assessment,
rather than the last-desperate hope

17. Agenda
• Common Challenges to Secure Software Development
• Integrity Checks and Security Assessments
• Internal and 3rd Party Security Considerations

18. Managing 3rd Party Risk
• 3rd party includes:
o Supplier of software you purchase
o Supplier of Software as a Service you consume
o Outsourced development team you leverage
• Managing risk includes:
o Setting expectations, including contractual language
o Validating expectations are met
o Clear remediation procedures to handle identified risks

19. Language Normalization
Term Definition
Vulnerability Security exposure that results from a weakness that the architect, developer, etc did not intend to
introduce
Threat A negative occurrence in the business processes of a system
Attack An implementation-specific action or set of actions taken against a system to realize a threat
Exploit Sequence of commands/activities that takes advantage of a vulnerability to cause unintended or
unanticipated behavior (i.e. gaining control of a system, privilege escalation, or a denial-of-service
attack)
Impact What damage can be done with a successful exploit
Risk The exposure and probability weighted ranking of a given threat, allowing for comparisons between
threats and across systems and factors in mitigating/compensating controls
It’s important to speak the same language
both internally and with 3rd parties

20. Understand the Risk you are Purchasing
• The ecosystem around software is constantly changing
• How “risky” software is has as much to do with vendor support as it
does to how secure the source code is
• Questions should be asked not just of software vendors that sell
applications, but also for vendors that offer software as a service.
• Contractual requirements should be put into place for outsourced
development

21. Consideration #1
Has Supplier Thought About Security?
• A contract does not replace diligence but given the frequency of
security breaches today, it’s important to:
o Determine what language you (the “Customer”) should minimally have with your
“Supplier” when sourcing a software application (the “Software”)
o Ensure that terms are defined to your acceptance and understood by supplier
• Ask the supplier to provide evidence of security due diligence
o Perhaps they have a 3rd-party or independent penetration testing doc to share
o Are they willing to attest to your security requirements and/or acceptance
testing…and offer remedies if they do not?

22. Suggested Contract Language
• E.g., the Software shall comply with all Documentation applicable
thereto, including, without limitation, the applicable Product
Requirements Documents, and Supplier shall develop the Software in
a professional, workmanlike manner in accordance with or exceeding
all industry standards, including security standards.

23. Consideration #2
Suppliers Secure Development Process?
• Often a vendor’s documentation is absent of security controls other
than a reference to industry standard(s)
• Vendor should demonstrate capabilities around integrating security into
each phase of development
• Many compliance mandates and customer requirements overlap
o Activities are generally the same, just worded differently
o Do the mapping ahead of time to consolidate requirements

24. Mapping Regulations & Mandates
• Most regulations, frameworks, and compliance mandates call out
general requirements and have non-obvious implications:
o “develop according to industry best practices”
o “protected information should not be improperly altered’”
• Vendor should demonstrate a repeatable SDLC that integrates key
security and compliance activities:
o Ensures future requirements will have little impact on existing efforts
o Allows you to maintain a “big picture” view to software development and IT teams
o Reduces “re-do” expenses and audit costs

25. OWASP Top Ten

26. High-Level
Requirement
Other Standards
(Partial List)
Selected Coding Practices
Confidentiality SOX, HIPAA, ISO
27002,, GLBA, FFIEC,
Basel l I, CA SB 1386,
FIPS 199, NIST
- 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, ISO 27002,
HIPAA, GLBA, FIPS
199, NIST
- 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, ISO 27002,
HIPAA, II, NIST SP
- 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, ISO 27002,
HIPAA, SB 1386, NIST
SP
- 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.
One secure coding activity yields
leverage across security controls
in 6 different standards

27. Other Questions to Ask:
Requirements • Do you gather security objectives? How are they mapped to the rest of the design
process?
Design • Does your team conduct security architecture and design reviews?
• Do you use checklists to drive the process? Do you revise them over time?
• Does your team create threat models to understand and prioritize risk?
Coding • Does your team use a formalized set of security coding best practices?
• What type of code scanning tools do you use?
• Do you perform code reviews against security best practices?
Testing • Does your team conduct 3rd party or internal penetration tests?
• Are your testers QA trained on the latest attack trends and test techniques?
• Do you use security testing tools?

28. Suggested Contract Language
• The Software shall comply with all Documentation applicable thereto, including,
without limitation, the applicable Product Requirements Document, and Supplier
shall develop the Software in a professional, workmanlike manner in accordance
with or exceeding all industry standards, including security standards.
• The Product Requirements Document mutually acceptable to Customer and
Supplier shall include each of the security elements set forth on Exhibit A
* Be certain to review with your legal counsel what information that is
confidential to your company that the application may access, and any
appropriate controls on confidential information, trade secrets or private
data

29. Principle Secure Development
Requirements
• “The software shall include the following secure application
development requirements”
o (a) a Data Criticality Definition (“DCD”);
o (b) security requirements based upon such DCD;
o (c) for each technology stack:
o i. Defined Architecture Standards
o ii. Defined Coding Standards
o iii. Defined checklists for use in architecture reviews, code reviews and penetration testing
o iv. Defined application security role-based training program for development team
o (d) Architecture and design review and threat model
o (e) Regular security code review and code scanning during development
o (f) 3rd party penetration test before release
o (g) Defined response plan for discovered vulnerabilities including how to deploy updates to Customer

30. Consideration #3
Commitment to Training?
• Is there a security training program in place
for all development team members?
• Is the training appropriate role and
technology based?
• Is there validation of security skills and
techniques?

31. Additional Items to Discuss
• What regular/recurring training does your development and test team
receive specific to application security?
• What percentage of your software development and testing team is
focused on security?
• Do you have a security team that attack your products prior to release
or is security embedded in each team?

32. Consideration #4
Security After the Delivery of Software
• Consider security for the whole lifecycle
• Production scanning or penetration testing?
• Cybersecurity insurance with customer as named beneficiary
• Make a penetration test an acceptance criteria
• Consider the supplier’s security and privacy policies

33. Suggested Contract Language
• Supplier shall at all times during the term of this Agreement maintain appropriate
technical and organizational measures to protect any Data that it collects, accesses or
processes in conjunction with this Agreement against unauthorized or unlawful use or
disclosure.
• Supplier shall implement security procedures to protect Data from improper disclosure
or use, such procedures to be in compliance with all industry standards and all
applicable federal and state regulatory requirements.
• Supplier will immediately notify Customer of any breach, or suspected breach, of data
security, (a “Security Breach”) and shall immediately coordinate with the Customer
security personnel to investigate and remedy the Security Breach, as directed by
Customer security personnel.
• Supplier shall maintain records of any known or suspected security breaches in
accordance with commercially accepted industry practices, and, if not prohibited by
applicable law, shall make such records available to Customer upon request.

34. …Continued
• In the event of a Security Breach, notwithstanding any other provision, Supplier shall
be solely responsible for all expenses related to the investigation of such breach as
well as the costs of furnishing notices to the other party’s affected customers and the
offer to such affected customers of services to mitigate the effect of such breach.
• Supplier shall not store any Data outside of the United States, other than an ISO
27014 certified facility, transfer any of the same to any location outside of the United
States or access or permit access to any of the same from any location outside of the
United States.
• At Customer’ discretion and Customer’ expense, no more than once in any given year,
Supplier shall cause a third party to perform a penetration test of all systems owned or
controlled by Supplier or its subcontractors that contain any Data.
• Supplier shall provide a summary of such results to Customer. If penetration testing
shows any material deficiencies, then Supplier shall use reasonable best efforts to
remediate all such deficiencies and shall provide Customer written documentation of
such remediation efforts.

35. Consideration #5
Vulnerability Service Level Agreement
• Cooperation after a suspected or known security breach may not be
adequate.
• Vulnerability SLA including response and turnaround time
• Terms and period of vendor’s security support agreement
• Tiers for different severity classes (clearly define)
• Dedicated team to assess and respond to security vulnerabilities
• How (or if) reported security defects are treated differently than
non-security defects.

36. Suggested Contract Language
In the event of a Security Breach or if Supplier has reason to believe a Software
vulnerability exists, Supplier shall respond within the specified turnaround time
according to the following service levels:
• (a) Critical: Attacker gains access to admin or root privileges allowing remote read
and write access to the system and remote commands.
• Response time: 2 to 3 hours
• Resolution time: Risk mitigated immediately (e.g. system offline if necessary),
risk resolved within 3 days.
• (b) High: Attacker gains user privileges or can execute a denial of service (DOS) for
any users on the system. Partial and/or read access to the sensitive data.
• Response time: 8 hours
• Resolution time: Risk mitigated within 1 day, risk resolved within 1 week

37. In Summary: 3rd Party Risk is Your Risk
• All software in your enterprise represents a security risk:
o Internally developed
o 3rd party vendor
o Outsourced team
• 3rd party is hard
o It's natural to want to 'trust' a 3rd party and
hope they are doing all the right things.
o It's hard to control 3rd party behavior
• Solution
o Clear expectations
o Backed by binding contractual
language

38. Further Information
In partnership with Security Innovation, Emenda can offer over
120 courses to help protect your business. To download our
latest course list, click here
For further information or to get in touch:
Contact Us
Visit Our Website