Validating Big data workflows
Tenendo helps to build a cost-effective and scalable Big Data validation strategy and implement it in your project.
In the world of Agile development, new versions and small updates are released daily for many companies, where small teams work side-by-side to improve products daily. Agile offers benefits including higher confidence by customers, the ability to make changes and fix issues immediately and in small increments, better, faster testing, and improved planning. Tech companies like Netflix, Etsy, and Amazon have become household names to watch, thanks largely to how they innovated (and continue to innovate) using the Agile methodology.
The Problem with Secure Software Development in the Agile Era
Our current situation is that most organizations have or are planning on adopting Agile principles in the next several years – yet few of them have figured out how security is going to work within the new methodology. The changes that Agile brings – frequent product releases and dynamic feature changes, among others – create a wholly different threat landscape from those posed by waterfall development methodologies.
There are plenty of reasons why security is left behind in many Agile organizations, but for the sake of brevity, we’ll break it down into two main issues.
Security is seen as a ‘Non-Functional Requirement’ (NFR), a requirement related to the state of the system, rather than, as the name suggests, functional areas of the system.
The problem with NFRs in Agile organizations is that they are hard to pin down in user stories, a main feature of the Agile methodology.
User stories follow a structure of “As a (type of user), I want/need (some goal/desire) so that (reason for goal/desire)”. Each requirement is crafted into a story with a reasoning for the requirement so that developers can plan for the experiences real people will have with the project. These stories closely guide team planning and development. Security requirements can be hard to turn into tangible stories. Especially given the fact that security controls often arise through risk aversion processes that include looking at the full threat landscape, security can be hard to pin down to one story in one application. It’s not impossible, but a lack of strong security user stories can easily prevent security from being planned or implemented correctly.
The second reason why security and Agile have historically been at odds is a lack of Agile-ready security practices and tools.
In waterfall methodologies, security planning is done at the beginning, while security testing is accomplished at the end. Security is missing from the whole middle part – the development process. While this may have worked to some degree in waterfall development organizations, it simply can’t in Agile. When it comes to Agile, security requirements and processes need to be synced up to business requirements. Security can’t (and won’t) be done in a vacuum – Agile organizations, and the security teams within them, need to make sure security fits in with the rest of the crew.
Creating a Secure Development Lifecycle in an Agile Organization
The process of integrating a secure development lifecycle into the Agile development process can be described by the following high-level steps:
- Put Developers in Charge of Secure Development
At this stage, we help formally define roles and responsibilities around the SDLC process, organize secure coding and code review training, create and maintain secure code review checklists, build the architecture vision taking into account security requirements. - Implement Continuous Integration Security Practices in the SDLC
During this step, we help you implement automated security tools such as static code analysis and scanners in the build pipeline. We also help define security deliverables such as automated tools reports (before minor releases) and manual penetration test reports (before major releases) as a part of quality gates. - Adapt, Iterate, and Grow to Keep Security Agile
Next, we help you maintain security awareness, organize knowledge refresh training, security retrospective, and lessons learning sessions, build and maintain a knowledge base. - Build a Security Culture through the Above Practices
As a result of previous steps, all secure SDLC sub-processes (risk analysis, continuous integration, security vision of the project) and artifacts (code review checklists, code analysis security metrics, vulnerabilities, and threats) become crystal clear, familiar, and easy to follow for everybody involved into SDLC process. - Build Security Through User Stories
At this stage, user stories are analyzed from the functionality and security perspective. All story’s specific security measures that prevent loss of confidentiality, integrity, and availability of sensitive information are designed based on the existing security architecture vision and consider the results of the risk analysis.
Achieving Secure SDLC Objectives
Successful implementation of the steps described above will allow your SDLC process to meet the main security objectives:
- Properly assign security responsibilities and resources
- Define software security policy and strategy
- Identify and mitigate threats and vulnerabilities
- Build and maintain secure change management, software integrity, and data protection processes
- Maintain a high level of internal communication and communication with the customers.
As a result, you will build and maintain a mature process of secure development and be able to confirm its compliance with industry standards, such as PCI Software Security Framework or ISO 27001.
Related services:
The New Way of Working
The new development and testing strategy implementation in the financial project
Test Environments Management
Lower test environment set-up and support costs.
Flexible and faster test environment provisioning and support services delivery.
End-to-end environment management.
