Many organisations have created security certification and accreditation processes. While these (sometimes) worked well in large waterfall projects, the transition to Agile projects break these frameworks. About Andrew Hood: Andrew has been working for over 20 years in the IT Networking and Security sectors including a range of companies from tiny dot coms to major international telecommunications companies. Having moved to New Zealand 10 years ago, Andrew is now responsible for the operational IT Security for one of the largest government departments. All of this means that he believes that there is nothing new in the IT industry, just different ways of learning from the same mistakes. Occasionally he wonders if we could stop making the same mistakes in the first place and if Agile might be a way of doing so.

1. Security Certification
Or: How I Learned to Stopped Worrying and Love Stories
Andrew Hood
IT Security Manager
Ministry of Social Development

2. About me
• I have no formal Agile qualifications
• Not been a developer for over 21 years
• Worked globally doing large scale data
networks
• Moved into IT Security
• About as Waterfall as you can possibly get

3. About that title…

4. Security Certification and Accreditation
A method of understanding the Information security risk of a
service and ensuring that risk owners are aware of the risk -
Section 4 of NZISM(plus most of section 3, bits of section 5,6,8,9 and lots of the rest of the 655 pages of the manual)
Certification:
• Documenting the residual risks in a system
• Documenting the controls used to mitigate risks
• Verifying that controls are mitigating the risk
Accreditation:
• Accepting the residual risks for that information type

5. Four Rules of Agile Security
1: IT Security is a Non-functional requirement
2: Failure to meet requirements generates risk
3: Risk controls are functional requirements
4: You must know your risk at all times

6. DevelopmentPlanning
Epic As a _____
I need _____
So that _____
Acceptance Criteria
Backlog
Dev Standards
Testing Output
Story
Feature
• Start to write security into functional and non-functional
requirements - use your Acceptance Criteria
• Do you have secure coding standards? Make them part
of your DoD, like automated OWASP security testing
passed
• Try to not write security stories
• Specific security controls are functional requirements
• Works for other non-functional like Performance
• Learning or Earning security? All security stories must
have business value – otherwise why are you doing
them?
Stage 1: Security in Stories

7. DevelopmentPlanning
Epic As a _____
I need _____
So that _____
Acceptance Criteria
Backlog
Dev Standards
Testing Output
Story
Feature
Security Processes
Risk
Security Risk Management Plan (SRMP)
• Security Risk Management Plan – know your risks,
mitigation controls and plans for remediation
• Your test failures are creating risk so:
1. Track them!
2. This is manual process
• SRMP needs pre-loading with standard risks and controls
(which feed your functional requirements)
Stage 2: SRMP

8. Security Processes
DevelopmentPlanning
Epic As a _____
I need _____
So that _____
Acceptance Criteria
Risk
Backlog
Security Risk Management Plan (SRMP)
Dev Standards
Testing Output
Story
Feature
Statement
Of
Applicability
Security Risk AssesmentSecurity Risk Assesment
• SRA – The Security Risk Assessment
• Manually created and normally slow
• Point in time risk snapshot for Certification and
Accreditation
• The technical part of the SRA is a snapshot of the SRMP
Stage 3: C&A

9. Security Processes
DevelopmentPlanning
Epic As a _____
I need _____
So that _____
Acceptance Criteria
Risk
Statement
Of
Applicability
Security Risk Assesment
Backlog
Security Risk Management Plan (SRMP)
Security Risk Assesment
Dev Standards
Testing Output
Story
Feature
Defects
• Lets join the dots together!
• You controls for Risks are updating your backlog with new
functional requirements for future stories
• Risk can now be linked to Epic or Feature
• Risk is now seen as part of a functionality, not total
service
• Stops go-live risk paralysis (at the last minute)
Stage 4: Link Risks to Benefits

10. Stage 5: Maturity
• Is this all too hard… or easier and cheaper?
1. You will find issues earlier and quicker
2. Resources costing may be lower
3. Key resources can work more projects simultaneously
4. As maturity increases, development standards and
story requirement become re-usable
5. You will need Embedded Security resources in story
writing sessions until mature
• Ahhhh… but what about Penetration Testing?

11. So what next?
• Work on your standards first
• Don’t expect BA/Dev/Testers to be able to do
it by themselves – help train them
• Find IT Security people willing to work this
way
• Hug your IT Security Manager and tell them
to stop worrying and love stories instead

12. Thanks for listening