Secure Software Development Lifecycle
Secure Software Development Lifecycle in Brief
A secure application development process combines the coders’ instructions, security policy requirements, reports for the management, as well as boundary conditions set by different standards.
Improving and increasing information security in the development process is a way to effectively build bridges between security, application development and the business processes. At the same time as security is enhanced, indicators are provided for the management and practical guidance is given to the employees. Measurability can be used to control both security objectives and budgets.
The creation of a security process starts with the analysis of the development work and the development model. Together we will find the key points where security is most essential. In support of the development process, process models are created of the security-related activities that must be performed during application development. We also create necessary materials that can be used in sales and marketing – you want to show you are up to date on security issues, don’t you?
What Mint Security Delivers
When the development is launched, short-term profits are sought and the long-term process objectives are specified. The end result is aimed at creating an effective connection to the company’s security and risk management system, data security requirements and customer promises.
The creation of a data secure application development process starts with the analysis of the development work and the development model. If needed, the current activity is audited and we can also walk into the organization to make observations or interview people working in different roles. Together we will find the key points where security is most essential. In support of the development process, process models are created of the security-related activities that must be performed during application development. Process models are customized out of ready blanks to fit companies that do traditional development, strive to do agile development, already do agile development or do extremely agile development. If you need to meet, for example, PCI-DSS or ISO27002 requirements, there are ready models also for these.
When improving the data security of the application development process, we utilize OWASP’s models, good practices, ready blanks and tested ideas. The good thing about open standards is independence.
To put it simple, our objective is to raise our customer’s readiness and ability to act according to the new demands while running their process with confidence and routine. With our experience of coding and architecture we are able to address the encoders and understand their need for a tangible approach. Our experience of data security, administration and measurement helps us to produce the transparency that the leadership wants.
Customer Needs and Challenges to Be Solved
The needs can be varied, but ultimately they are rather generic.
- Managing data security requirements in application development
- Formalizing certain application development processes and act according to them
- Unifying the set of criteria for acceptance testing with regard to data security
- Assessing the threats and risks associated with application development and its results
- Providing confidentiality and value to customer relationships
- Measuring security – combining data sources and using existing information more effectively
One of the major challenges is that the company’s security department and application development are too loosely connected. Data security does not have the time or the potential – or at times even the knowledge – to be integrated into the application development process. Stronger connections to data security can be created using various virtual organization structures, team responsibilities and modern champion/coach roles suitable for agile work. By sharing responsibility, a new kind of grass-roots ownership of project security and risk management is produced. Often processes need to be modified so that data security and risk management are more closely integrated into them. When security is a solid part of the application development, it is not seen as an external matter.
Lastly, the indicators and gates related to data security must also be designed and thought out. A model where the organization feels that security only means there are certain chores that have to be performed so that the reports look good will undermine the issue, namely data security and risk management. In agile organizations the definition of secure, which supports the definition of done, will guarantee that the sprints contain concrete work and measurability.
More Details about Our Methods and Tools
The Good Enough Approach
In order to get the right inputs to the right areas, security domains are defined. The task of the areas is to ensure that the right indicators control the right operations and that the necessary sub-areas receive the right kind of attention. Similarly, it is also important to ensure that there is not too much emphasis on areas with low criticality. Every issue cannot be the most important one. For example, the OWASP ASVS framework can be used for requirement definition.
Specifically, the following are defined, among other things:
- Data security functions
- Data security requirements and minimum levels
- Audit requirements
- Logging and log management requirements
- Code audit requirements
In order to measure the requirements of the application development process in a neutral manner over time, it is essential to use a third-party indicator that is well-known, common and unquestionable. Owasp SAMM is a maturity-based indicator for the application development process. Owasp SAMM is best suited for measuring strategic goals and can be used both as an interview tool and for evaluating various types of data security road maps.
As the application development team develops and the goal is to integrate data security into a more natural and effortless part of the operations, it is very efficient to name virtual team leaders who take charge and are trained in accordance with their own areas of interest. The areas to be chosen depend entirely on the organization’s need.
For example, the following areas can be considered:
- Technical data security and architecture
- Technical data security in web applications
- Administrative security and the Finnish Government’s standard frameworks (Vahti and Katakri)
- General and commercial standards for administrative data security (ISO27002 and ISO31000)
- Open models for administrative data security (OWASP)
- Threat modelling
- Risk management
- Incident management
Preparing for Third Party Code Auditing
Audit usually refers to a code review by a third-party expert. The audit report will improve product development and eliminate potential recurring problems. Successful auditing is part of the security process, so that errors that are once detected will not be repeated. We help define audit needs and get the most out of auditing. The audit report will be utilized in full, it will not be left to collect dust. We will jointly analyze the results and reports and plan any follow-up actions.
Continuous Integration & Delivery and Automation
In today’s professional application development, various release management tools are used. Continuous integration and delivery are both so called buzzwords. Many organizations have proper development tools, but they lack data security aspects. Safety indicators and automated data security audits can be included in the process. To reach easy and transparent data security, you need the right indicators, operating models and tools.
Continuous Measurement of Software Security
Software security is all too rarely combined with measuring. Measuring can improve the development processes and show that development is effective and safe. The measuring is based on logs produced by different systems and data out of which desired screens and reports are aggregated. Measuring requires certain skills within the organization, such as innovation of instruments and management of logs and measurement data.
Over the last 10+ years, OWASP SAMM has proven an effective model for improving secure software practices to a wide variety of organizations. Release v2 of SAMM adds automation along with maturity measurements which assess both coverage and quality. Here we look at some the new features and changes compared to the previous version.
Määrittelemällä tietoturvan tasolle omat vaatimusalueet, security domaineja, voidaan välttyä sekä ali- että ylisuorittamasta tietoturvaa. Kaikki vaatimukset pyritään johtamaan ylhäältä organisaatiotason vaatimuksista.
Uhkamallinnus on olennainen osa modernin ja ketterän sovelluskehitysprosessin tietoturvaa. Työkaluna voidaan käyttää Microsoftin EOP -korttipeliä. Korttipeli on erityisen soveltuva agile-malliseen työskentelyyn, sillä tiimit ovat jo tottuneet erilaisiin pelillisiin lähestymistapoihin. Peli on hauska, ja sillä saa hyviä tuloksia aikaiseksi (tekemättä mitään oikeita töitä).
OWASP tuottaa avoimen lähdekoodin periaatteella materiaaleja kaikkien käytettäväksi. OWASPin materiaaleja ei ohjaa kaupallisuus ja materiaalien ideointiin, suunnitteluun ja toteutukseen osallistuu parhaimmat tekijät. Tästä syystä on helppoa suositella erilaisten OWASP-peräisten mallien käyttöönottoa. Jos on kiinnostusta voi itse kukin osallistua erilaisiin OWASP-työryhmiin. Tällä tavoin on mahdollista itse vaikuttaa siihen, miltä työkalujen seuraavat versiot näyttävät ja mitä ne sisältävät.