Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Delivering Secure Projects

207 views

Published on

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

Published in: Business, Technology
  • Be the first to comment

Delivering Secure Projects

  1. 1. Internal Presentation July 2013 Phil Huggins
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 13 Stakeholder Business Goals Use Cases Functional Requirements Non- Functional Requirements Design External Constraints • Design Decisions • Trade-Offs
  14. 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. 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. 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. 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. 18 http://blog.blackswansecurity.com

×