A short run through of my experience and advice in delivering security in critical projects. Presented at an internal forum in July 2013.

1. Internal Presentation July 2013
Phil Huggins

2.  I have lead large delivery
programmes:
 Multiple projects
 Challenging stakeholders
 Large, complex systems
 Multi-year delivery
 100+ people customer
delivery teams
 200+ people supplier delivery
teams
 Need to know
 High threat
2

3.  By the end of this sessions you should:
 Be able to identify delivery projects where
security is a critical attribute
 Understand the potential issues is secure project
delivery
 Suggest possible ways of preventing or handling
issues
Company Confidential 3

4. 4
Governance
Risk
Management
Compliance
Requirements
Management
Security
Architecture
Threat Analysis
Risk
Assessment
Supplier
Selection
Procurement
Stakeholder
Management
Design
Trade-Offs
Build
Supply Chain
Management
Testing
Transition to
Operation
Legacy Estate
Management
Release
Management

5.  These are the activities that mean there are no
surprises during the project. Everyone knows what is
happening and when it is happening.
 ‘Bringing stakeholders on the journey’
 Identify security red flag holders.
 Legacy estates always include problems to solve to
meet current requirements.
 Understand and document the As-Is environments.
 Establish fixed requirements review cycle, agree SLA
with stakeholders for response
 Use reference architecture to assure requirements
coverage.
 Establish a SecurityWorking Group early.
 Include; suppliers, security decision makers,
operational management, specialists
5
Requirements
Management
Stakeholder
Management
Legacy Estate
Management

6.  Clear sponsorship for security
from the project sponsor or his
boss.
 Who ‘owns’ the security?
 Do they control project budgets?
 Established escalation paths.
 What ‘red lines’ can’t be crossed?
 Establish the format for security
cases to request risk acceptance.
 This is the ‘air cover’ needed for
unpopular security decisions.
6
Governance
Risk
Management
Compliance

7.  This is the core security content of what you
are doing.
 This is how you measure and plan the security
delivery.
 This is the basic justification for the security
requirements, if this is wrong you will lose
credibility in every other activity.
 Establish a security documentation framework
at project initiation and fill it in as you go
 Build a reference architecture
 Run a ‘dry-run’ risk assessment against it.
7
Security
Architecture
Threat Analysis
Risk
Assessment

8.  The security principles or maxims
 And
 The security model of the system
 And
 The security requirements
 And
 The security relevant design decisions
 And
 The security controls as actually
implemented
8

9.  This is your opportunity to identify a partner you can
work with.
 If you don’t give suppliers explicit security requirements
and expectations in procurement you will be fighting
them all through the project.
 Make sure they ‘get’ security.
 Understand who their subcontractors are, where they
are buying their hardware, how they expect to ramp up
their team and when they expect to start delivering
physical kit.
 Share explicit security requirements and the reference
architecture with suppliers.
 Write your testing strategy into the procurement!
 Establish a deliverable assurance process with your
chosen supplier immediately following contract award.
9
Supplier
Selection
Procurement
Supply Chain
Management

10. 10
Supplier
Maturity
Customer
Maturity
Needs
specified
and fulfilled
Needs
specified
but not
fulfilled
Needs not
specified
and not
fulfilled
Needs not
specified
but fulfilled
Over-delivery
Under-delivery
No-delivery
Delivery

11.  Work hand-in-glove with the
suppliers.
 Every time they go away and design
in isolation you risk rework and
delay.
 Document design decisions clearly.
 Follow your formal deliverable
assurance approach.These will start
coming thick and fast, they won’t
wait for you for long.
 Identify impact of design decisions
and trade-offs on the requirements.
11
Design
Trade-Offs
Release
Management
Local Hero Phenomenon
• Lack of requirements
• Lack of standards
• Reliance on expertise

12.  Functional Requirement
 What a system must do.
 Interaction between a component and the environment.
 Testable.
 Non-Functional Requirement
 How the system will do it.
 Restricts the manner of operation of the system.
 General in scope and concern the whole system
 Security Requirement
 A manifestation of a high-level security policy into the detailed
requirements
12

13. 13
Stakeholder
Business
Goals
Use Cases
Functional
Requirements
Non-
Functional
Requirements
Design
External
Constraints
• Design Decisions
• Trade-Offs

14.  This is where your agreements with your
supplier will start to fall apart.
 Some designs won’t work in practice.
 Mistakes in implementation will be made.
 Some will take longer than expected.
 Some requirements will change.
 Standing up the development team is a
major cost to the supplier.
 Physical delivery of kit is expensive to
reverse.
 Be flexible and be prepared to make
decisions quickly.
 Don’t let suppliers disappear off down theV
model with the words ‘See you in test’.
14
Build

15.  SecurityTest Strategy
 What is being tested
 When in the project it must happen (Early testing reduces defect
rates)
 SecurityTest Plans
 What sort of tests
 What standards or requirements are being tested?
 Acceptance criteria
 Types of tests to consider:
 Automated Static Code Analysis
 Manual Source Code Analysis
 Risk-BasedTargeted PenetrationTests
 Internal penetration tests
 Independent Full-Scope PenetrationTests
15
Testing

16.  Ensure operations team sit on the
SecurityWorking Group
 Make sure the operations team have
been properly introduced to the key
stakeholders
 Make sure the operations team
establish communications channels
with key stakeholders.
 Give them visibility of design, build
and test phase artefacts and risks.
 Plan to hang around for a few weeks
or months following handover
16
Transition to
Operation

17.  Get to know your key stakeholders very well,
they can be your strongest supporters.
 If you don’t document it no-one else will
 If you don’t tell anyone they won’t do anything
 If you’re not paying for it probably won’t happen
 Be aware of the time / cost implications of your
decisions
 Work in partnership with suppliers but make sure
you have the documentation to win a fight.
 Don’t become irreplaceable!
17

18. 18
http://blog.blackswansecurity.com