In order to stay resilient to these breaches, it is crucial for organisations to take a proactive approach to security and weave it into the fabric of their culture. Secure development must be a part of a new company policy.

Is DevSecOps just another buzzword or rather a necessity? How to increase ROI through software security? Why align security and compliance and how to measure security requirements? You will find answers to these – and many other important questions – in our newest whitepaper on software security.

Protecting Your Business

According to the latest Symantec Internet Security Threat Report, in the last 8 years more than 7.1 billion identities were exposed in data breaches.

New classes of attacks, such as ransomware and targeted espionage attacks show new levels of cybercriminal ambition. Additionally to potential financial losses, such attacks have an unquantifiable, negative impact on customer confidence and on brand value.

The new GDPR law will introduce a great challenge for all organisations that process personal data. Building the software with security-in-mind approach (which includes regular testing, vulnerability assessment and penetration testing – both using automated tools, and as an expert-driven manual process) allows organisations to go beyond today’s compliance requirements, enabling them to be proactive and forward-thinking.

The Ponemon Cost of Data Breach Study shows that the global average cost of data breach is $3.62 million. The average cost for each lost or stolen records containing sensitive and confidential information was measured as $141 in the study.

The report includes data from 419 companies in 13 countries or regions. It also states that the cost of a data breach depends on the industry, indicating healthcare organisations and financial services leaks as the most costly.

Businesses operating in these industries should ensure that they have a proper security programme in place. The predictions are that the threats are set to worsen. Adoption of new technologies (IoT, Cloud Computing, mobile devices) expands the threat landscape.

New bugs and vulnerabilities are discovered every day. And most of the websites serving malicious content were once legitimate websites that have been compromised by attackers.

BREACHES	2014	2015	2016
TOTAL BREACHES	1,523	1,211	1,209
BREACHES WITH MORE THAN 10 MILION IDENTITIES EXPOSED	11	13	15
TOTAL IDENTITIES EXPOSED	1,2B	564M	1,1B
AVERAGE IDENTITIES EXPOSED PER BREACH	805K	466K	927K

Secure Development Must Be Part of Company Culture

Development lifecycle is a process which guides developers on how to build software. It usually contains the following phases:

• Training
• Requirements
• Design
• Implementation
• Verification
• Release
• Response

Secure Development Lifecycle extends regular develop – ment by adding activities on top of the existing process. It ensures that security is not only considered during the testing phase, but remains a continuous concern. Correctly implemented Secure Development Lifecycle allows to build more secure software, helps in address – ing compliance requirements and reduces the total cost of development.

While process implementations might vary in detail, the core is common – “shifting left”, where practices and secure principles are applied in a holistic manner to the whole development process.

Three steps are required for successful implementation of the process. Firstly, developers, managers and IT pol – icy makers must identify which requirements for security are based on data processed by the application. As a second step, the organisation must assess the current state of security in the software development process. This allows to identify gaps and create a proper roadmap for advancing in security maturity level.

There are several publicly available and documented Secure SDLC processes that can be used to ensure security of developed software:

• OWASP Secure Software Development Lifecycle Project
• NIST System Development Life Cycle (SP 800-64, Revision 2)
• Microsoft Secure Development Lifecycle 5.2 (and SDL for Agile)
• BSIMM (Building Security In Maturity Mode)

Microsoft Secure Development Lifecycle

Microsoft SDL is a secure development process that was started by Microsoft’s Trustworthy Computing team,
as a response to Bill Gates’ memo sent to all Microsoft employees in 2002. It called for the following fundamental security features to be present in computer systems:

Since 2004, the process has been mandatory for all Microsoft products and it is being constantly improved, accepted and adapted industrywide.

The Microsoft SDL process is well-documented, with step[1]by-step instructions to be used by a development team to increase the level of security. A set of training presentations, tools and guides are provided.

Better ROI

The National Institute of Standards and Technology (NIST) claims that code fixes done during the design and implementation phase can be 30 times less expensive than the ones performed after the release.

This way security development lifecycle can help to reduce the total cost of development. The amount of time spent on post-development bug remediation, incident response and customer service also decreases.

SANS Institute states that including security aspects in the requirements for software and cloud services not only efficiently reduces attack surfaces, but has also been proven to reduce time to market for secure business services.

SDL for Agile

SDL for Agile is a way to integrate the security related activities into the Agile development process, which is based on fast and frequent delivery. This approach requires ensuring that security practices do not interfere with delivery cycle and, at the same time, makes sure that no crucial practices are missing. The practices are divided in three categories:

Every sprint practices

Essential security practices that should be performed in every release. Some examples include:

• Threat modeling,
• Running static code analysis tools, and
• Ensuring that defensive coding techniques are used, e.g.: ensuring all database access is performed through parameterised queries to stored procedures, mitigating against cross-site scripting (XSS), using safe redirect u Using secure cookie over HTTPS.

Bucket practices

Important security practices that must be completed on a regular basis but can be spread across multiple sprints during the project lifetime. Examples include:

• Conducting a security review,
• Creation of privacy-related documents,
• Fuzz testing,
• Attack surface analysis, and
• Data flow and input validation testing.

DevSecOps – buzzowrd or necessity?

DevSecOps is a concept which connects traditional DevOps and Security engineers. It accepts the fact that the responsibility for secure development lays not only on a limited number of security engineers, but on the whole development teams. It puts the focus on introducing automation of security activities.

DevSecOps is a list of t of rules defined to make your security effort work for your project, not against it:

• Leaning in over Always Saying ‘No’,
• Data & Security Science over Fear, Uncertainty and Doubt,
• Open Contribution & Collaboration over Security-Only Requirements,
• Consumable Security Services with APIs over Mandated Security Controls & Paperwork,
• Business Driven Security Scores over Rubber Stamp Security,
• Red & Blue Team Exploit Testing over Relying on Scans & Theoretical Vulnerabilities,
• 24×7 Proactive Security Monitoring over Reacting after being Informed of an Incident,
• Shared Threat Intelligence over Keeping Info to Ourselves, and
• Compliance Operations over Clipboards & Checklists.

This includes incorporating the following into Continuous Integration and integrated development environments (IDEs):

• Static code analysis (which should include security-related rules),
• Dynamic testing (using scanners)
• Automation of security requirement checks
• Planning and implementing security features (Security as a Code)
• Ensuring secure deployments (Infrastructure as a Code)

Another important part of SecDevOps responsibilities is introducing best practices and developing security culture.

Measuring and Enforcing Security Requirements is part of the process

Capturing security requirements for your project before actual development has been commenced pro[1]vides many advantages, e.g.:

• Gives better understanding of application security risks and possible remediation to management, development team and Business Analysts,
• Makes you compliant – when done right, security requirements are based on privacy analysis and compliance requirements that apply to data stored and processed by the system,
• Makes security work anticipated, planned and cost-bound – adding security non-fictional requirements as Acceptance Criteria for User Stories makes them easy to use during estimation, development, and ensures easy mapping between requirements and controls applied during development process,
• Makes them testable – once you define a requirement, it can be included in the test activities, and
• Improves transparency of contract with the supplier – when using a third party for software development, agreeing on a detailed list of requirements will ensure a common view on what a secure application is.

OWASP Application Security Verification Standard is  a well-established framework that can be used to build a set of actionable and measurable security requirements. ASVS 3.0.1 requirements cover the following features of a system:

• V1.Architecture, design and threat modeling
• V2. Authentication
• V3. Session management
• V4. Access control
• V5. Malicious input handling
• V7. Cryptography at rest
• V8. Error handling and logging
• V9. Data protection
• V10. Communications
• V11. HTTP security configuration
• V13. Malicious controls
• V15. Business logic
• V16. File and resources
• V17. Mobile u V18. Web services (NEW for 3.0)
• V19. Configuration (NEW for 3.0)

Requirements are grouped into three security verification levels:

• ASVS Level 1 contains a basic list that can be applied to all applications,
• ASVS Level 2 should be used for applications containing assets which require protection,
• ASVS Level 3 is for the most critical systems – medical equipment, applications containing valuable, intellectual property or processing a vast amount of financial transactions.

Security and compliance should be aligned

Systems used to process sensitive data (medical data, credit cards, Personally Identifiable Information) need to comply with complex regulations and laws related to system security.

Standards such as General Data Protection Regulation (GDPR), Payment Card Industry Data Security Standard (PCI DSS), Health Insurance Portability and Accountability Act (HIPAA) or ISO/IEC 27001 Information Security not only require you to protect the data, but also introduce financial fines for the lack of proper security controls.

Standards recommend to regularly test applications and infrastructure for vulnerabilities. This can be done by penetration testing and vulnerability scanning. Penetration testing, when performed by a skilled and experienced individual, tests real-world risks to the business and verifies the actual state of system security. It will uncover problems that would not be found by automated tools.

PCI DSS

PCI DSS requires to fulfil the following goals through penetration testing: ’determine whether and how a malicious user can gain unauthorised access to assets that affect the fundamental security of the system, files, logs and/or cardholder data. Confirm that the applicable controls, such as scope, vulnerability management, methodology, and segmentation, required in PCI DSS are in place.’

ISO 27001

ISO 27001 security control objective A12.6 (Technical Vulnerability Management) states that ‘information about technical vulnerabilities of information systems being used shall be obtained in a timely fashion, the organisation’s exposure to such vulnerabilities evaluated and appropriate measures taken to address the associated risk.’

GDPR

GDPR requires to ensure that security measures of systems used to store and process Personal Data (any information about an identified or identifiable individual) are regularly tested.

NIST guide for implementing the HIPAA

NIST guide for implementing the HIPAA recommends to conduct penetration testing (where trusted insiders attempt to compromise system security for the sole purpose of testing the effectiveness of security controls), if reasonable and appropriate’.

We hope this article has helped you understand the importance of security in software development.