{"id":1471,"date":"2014-09-05T14:53:48","date_gmt":"2014-09-05T14:53:48","guid":{"rendered":"https:\/\/blogs.gov.scot\/digital\/?p=1471"},"modified":"2017-07-20T09:19:35","modified_gmt":"2017-07-20T09:19:35","slug":"security-within-agile-environments","status":"publish","type":"post","link":"https:\/\/blogs.gov.scot\/digital\/2014\/09\/05\/security-within-agile-environments\/","title":{"rendered":"Security within agile environments"},"content":{"rendered":"

This is a post by Neil Campbell, our Information Security Officer and is part of our series on <\/i>Standards & Guidelines<\/i><\/span><\/span><\/p>\n

Security within agile environments can be challenging. There\u2019s a need to juggle a large number of competing factors including velocity, compliance requirements, ambitions around user experience and adherence to standards \u2013 all while maintaining the flexibility\u00a0required to deliver a\u00a0great product for our users.<\/span><\/p>\n

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

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.<\/span><\/p>\n

Our mechanisms for managing risk<\/b><\/span><\/p>\n

We have a number of mechanisms in place for managing risk, specifically in relation to security.<\/span><\/p>\n

Identification<\/b><\/span><\/p>\n

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.<\/span><\/p>\n

Communication<\/b><\/span><\/p>\n

it\u2019s important the management of security risks be\u00a0<\/b>integrated into the wider management of risks within\u00a0programme. This will allow a balanced view of these\u00a0risks along side others including\u00a0usability, cost and delivery. Use different risk categories to facilitate discussions with the most appropriate\u00a0audience. Typical audiences include scrum teams, security stakeholders and technical architect.<\/span><\/p>\n

Evaluation<\/b><\/span><\/p>\n

At this point the\u00a0<\/b>team, technical architect and information asset owner level evaluations should\u00a0take 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.<\/span><\/p>\n

Mitigation controls<\/b><\/span><\/p>\n

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.<\/span><\/p>\n

Our security models<\/b><\/span><\/p>\n

In order to obtain and maintain a shared understanding of the security landscape of\u00a0mygov.scot<\/span><\/a>, we made use of a number of publicly available models that would meet our needs.<\/span><\/p>\n

Security governance model<\/b><\/span><\/p>\n

This identifies the security stakeholder both within and out with the programme, ensuring a clear understanding exists of whom is responsible.<\/span><\/p>\n

Security stakeholder map, analysis, models and communication plan<\/b><\/span><\/p>\n

These documents identify roles, their influence, any associated concerns, what information to share with them and the best ways to communicate\u00a0and keep them up to date.<\/span><\/p>\n

Data architecture<\/b><\/span><\/p>\n

The cornerstone of any security is the data within the service. Security decision need to take into account the implications for the\u00a0actual data.<\/span><\/p>\n

Security design<\/b><\/span><\/p>\n

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\u00a0to understand discrepancies in thinking, which could then be addressed to form a\u00a0more complete view with those involved.<\/span><\/p>\n

Security framework<\/b><\/span><\/p>\n

Our\u00a0mygov.scot<\/span><\/a>\u00a0implementation utilises the ISO 270001 <\/span><\/a>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.\u00a0This also covers internal and external assessment.<\/span><\/p>\n

Options for integrating security<\/b><\/span><\/p>\n

Integration with sprint planning<\/b><\/span><\/p>\n

The security design draft allows for a baseline to be set. Teams can then ask themselves the question \u2013 \u201cDo we need to deviate from the security design in this sprint?\u201d.<\/span><\/p>\n

If a deviation is required it is possible to correct this through:<\/span><\/p>\n