Over-delivery & Local Heroes tends to result in domain specific requirements being missed.
Domain specific security requirements are hard, suppliers are much less likely to have expertise in these up front.
Delivering Secure Projects
Internal Presentation July 2013
I have lead large delivery
Large, complex systems
100+ people customer
200+ people supplier delivery
Need to know
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
Suggest possible ways of preventing or handling
Company Confidential 3
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
Establish a SecurityWorking Group early.
Include; suppliers, security decision makers,
operational management, specialists
Clear sponsorship for security
from the project sponsor or his
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.
This is the core security content of what you
This is how you measure and plan the security
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.
The security principles or maxims
The security model of the system
The security requirements
The security relevant design decisions
The security controls as actually
This is your opportunity to identify a partner you can
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
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.
Work hand-in-glove with the
Every time they go away and design
in isolation you risk rework and
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.
Local Hero Phenomenon
• Lack of requirements
• Lack of standards
• Reliance on expertise
What a system must do.
Interaction between a component and the environment.
How the system will do it.
Restricts the manner of operation of the system.
General in scope and concern the whole system
A manifestation of a high-level security policy into the detailed
• Design Decisions
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
Be flexible and be prepared to make
Don’t let suppliers disappear off down theV
model with the words ‘See you in test’.
What is being tested
When in the project it must happen (Early testing reduces defect
What sort of tests
What standards or requirements are being tested?
Types of tests to consider:
Automated Static Code Analysis
Manual Source Code Analysis
Internal penetration tests
Independent Full-Scope PenetrationTests
Ensure operations team sit on the
Make sure the operations team have
been properly introduced to the key
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
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
Work in partnership with suppliers but make sure
you have the documentation to win a fight.
Don’t become irreplaceable!