Digital

Security within agile environments

September 5, 2014 by Jono Ellis No Comments | Category Digital Public Services, mygov.scot

This is a post by Neil Campbell, our Information Security Officer and is part of our series on Standards & Guidelines

Security within agile environments can be challenging. There’s a need to juggle a large number of competing factors including velocity, compliance requirements, ambitions around user experience and adherence to standards – all while maintaining the flexibility required to deliver a great product for our users.

We thought about best practice in relation to security, and for risk, balancing these so we had something we could work with. Risk in the mygov.scot programme is being used to balance complex and at times competing factors, allowing us to have a well rounded response.

As part of our risk management we are looking to ensure that the landscape people make decisions in is current. Security decisions should be reviewed, ensuring the service remains appropriately secure.

Our mechanisms for managing risk

We have a number of mechanisms in place for managing risk, specifically in relation to security.

Identification

Risk identification this should be performed by all team members, stakeholders and any external 3rd parties. Subject matter expertise should be provided to quantify the risk.

Communication

it’s important the management of security risks be integrated into the wider management of risks within programme. This will allow a balanced view of these risks along side others including usability, cost and delivery. Use different risk categories to facilitate discussions with the most appropriate audience. Typical audiences include scrum teams, security stakeholders and technical architect.

Evaluation

At this point the team, technical architect and information asset owner level evaluations should take place. These confirm the acceptable target level for the risks and identify those that are currently an unacceptable level, which will then require mitigation or elimination.

Mitigation controls

Once the risks have been identified as requiring mitigation or elimination, then solutions can be proposed, designed, evaluated and implemented to reposition the risk to an acceptable level.

Our security models

In order to obtain and maintain a shared understanding of the security landscape of mygov.scot, we made use of a number of publicly available models that would meet our needs.

Security governance model

This identifies the security stakeholder both within and out with the programme, ensuring a clear understanding exists of whom is responsible.

Security stakeholder map, analysis, models and communication plan

These documents identify roles, their influence, any associated concerns, what information to share with them and the best ways to communicate and keep them up to date.

Data architecture

The cornerstone of any security is the data within the service. Security decision need to take into account the implications for the actual data.

Security design

A high level view is important to help us understand what security controls are implemented and by whom. We have multiple teams working alongside 3rd party suppliers on a daily basis, so getting this right is critical. This enabled people to understand discrepancies in thinking, which could then be addressed to form a more complete view with those involved.

Security framework

Our mygov.scot implementation utilises the ISO 270001 baseline control set. It has been set as the security framework of choice, providing the detailed design information regarding security controls delivered for our programme. This also covers internal and external assessment.

Options for integrating security

Integration with sprint planning

The security design draft allows for a baseline to be set. Teams can then ask themselves the question – “Do we need to deviate from the security design in this sprint?”.

If a deviation is required it is possible to correct this through:

• Updating the security design draft to reflect any new information or decisions made, in turn reflecting them in the risk register
• The addition of items to the backlog, correcting any temporary deviation through future sprints

In our alpha this allowed us the flexibility to compensate for a lack of formal operating procedures in early sprints with peer review and a close working team. This also allowed for the information asset owner to accept the higher risk of not using intrusion detection in all environments for the alpha.

Integration with retrospectives

Integrating with retrospectives allows teams to answer  – “Did we need to deviate from the draft security design in that sprint?”.

It is then possible to identify how to correct a temporary deviation or to record a permanent change. This gave us the flexibility to deliver manual server builds while scripted builds were being developed, with additional stories in the backlog to rebuild the manually built services through automated processes when available.

Implementing security controls

Still with us? Then the final piece of the puzzle is the implementation of security controls in your environment. These can be implemented through:

• Technology – such as firewalls or source repository version control
• Procedural  – such security quality attributes and penetration testing
• Policy – such as those for data protection

Security and agile, they need not be polar opposites. Any recommended best practice should always be shaped for your environment. This helps to make things work smoothly, so keep that in mind when planning your own approach!

We’ll be sharing this post and more on social, so follow the team via @mygovscot on Twitter for more updates. Have a comment? Let us know below!

Tags: Standards & Guidelines, Technology & Digital Architecture

Comments