View
20
Download
0
Category
Preview:
Citation preview
Mature Security Testing Framework June 2015
Typical security testing approach
Client pain and challenge –
• Tick box approach to project completion
• Client or project manager unsure on scope or what
to scope
• Only a fraction of the environment is tested
• Disconnect in risk management vs. critical systems
or data
• Unsure on regulatory and compliance requirements
• Set or minimal project budget
• Squeezed or limited timelines for delivery
• Asset overlapping leading to wasted revenue
• Reactive penetration testing to project pipe
Security testing framework
What is a framework?
• A framework seeks to standardise structure and approach
What is a penetration testing framework?
• Benefits -
• Improved security posture and landscape
• Standardised and structured approach
• Scheduled and organised delivery
• Enterprise wide adoptable approach
• Early indicative costing of annual BAU
• Defined requirements for project based security testing
• Reduced security testing costs and budgets
• Multiple supplier support & reduced supplier costs
• Defined metrics on vulnerability management
Framework strategy & governance
How to determine strategic approach
• Mission objectives and risk appetite -
• Defined accountability to individuals
• Head of penetration testing?
• High detection rate of vulnerabilities leading to
tolerable acceptance of risk through cost
effective ROI.
• Meet regulatory and compliance requirements.
• Defined requirements for executing assessments
• Meet change control policy and requirements.
• Be wary of organisational influences -
• Is the organisation evolving and expanding?
• Frequent changes to infrastructure and
applications?
• Regulatory and compliance changes
Asset and system discovery
Determining what you have and where..
• Departmental and organisational discovery and
analysis
• What is critical to the business?
• What are critical systems to each
department?
• Asset and system lists
• IT department
• Finance department
• Risk department?
• Network discovery
• Internal, External, Third parties
• Capturing that information
• Word document
• Spread sheet….
Categorize and profile systems or
assets • Questions that need to be asked quickly
to score a system and build a profile
(qualitative) e.g.
• Is it externally facing? (likelihood)
• Does it contain corporate or credit
card or PII data
(impact/consequence)
• Is it a business critical or core
system or asset?
• Who accesses it and how?
• When was it tested last?
• What compliance or regulatory
requirements are there?
• ISO27005, OCTAVE, (IT RISK), AS/NZ
4360, NIST
• Risk and business impact analysis
• Defining asset criticality through
quick question qualitative
(subjective value) approach. Or;
Quantitative (numbered value).
Define a value..
• Likelihood of attack -
• Exposure to threat
• Consequences / impact -
• Business impact
• System status –
• Dynamic or static?
• Security assessment status -
• When was the last test?
• Compliance and regulatory
requirements overrule everything.
Possible BAU testing schedule..
External
• Daily or weekly differential scanning.
• The internet facing footprint is subject to a VA scan
quarterly at a minimum..
• All external facing assets and services are subject to a
pen test on a defined risk based schedule (1-3 years)
Internal
• All internal assets are subject to a VA scan quarterly.
• All internal critical assets and services are VA scanned on
a monthly basis.
• All critical internal assets and applications are pen tested
on a defined risk based schedule (1-3 years).
External and Internal
• All internal and external assets, systems, services and
applications are subject to a penetration test upon a major
change or under project testing schedule.
Example BAU approach
• External Brochureware static website –
• No PII, Credit card, corporate data
• Impact = Low
• Likelihood = Medium
• = application and infrastructure test
every three years
• Internal business critical CRM application
accessible by all employees –
• Corporate data, PII information
• Impact = Catastrophic
• Likelihood = Medium
• Minor changes to code base
• = pen test every 1 year / va scan
monthly
BAU Scoping testing activities..
NCC Group approach..
• What is it?
• Who uses it?
• Why do they use it?
• How do they access it?
• What do they do on it?
• What data is stored on it?
• What does it sit on?
• What does *it* access?
What helps to scope?
• Architecture diagrams with data flow
• High level design documents with clear explanations.
• Access to the system or asset for review – especially web
or mobile applications!
“Agile” BAU software development
changes?
BAU “Big Data” mining
Project Structure
Defining what the project structure looks like..
• Map what is coming down the pipe (6 months to two
years!) – get involved on those project meetings…
*(Sigh)*
• Map testing requirements early on in the project lifecycle
• What is the project?
• Is it business critical?
• What is the impact?
• What is the likelihood?
• What assets are there?
• What information does it process, transmit, or
store?
• Compliance & regulatory requirements.
• For projects we may want to define some set tests to
ensure that the environment or application is secure
before launch and promotion to BAU *
*variable sampling is recommended due to cost
Project minimum baseline..
All about that baseline..
• Think proactively about the assets involved
• External = external penetration test / firewall rule
review
• Application = application test
• Mobile asset = operating system build review
• Database = internal penetration test & DB review
• At a minimum we may want to consider for all assets -
• Vulnerability Assessment scan.
• Infrastructure level penetration testing of sampled
assets*
• Operating system build reviews – hypervisor,
networking, servers, clients
• Firewall configuration or rule review (if necessary)
• Application testing (mobile/web) (if necessary)
Reducing costs through mapping..
Security testing overlaps
• Why map assets?
• Determine common recurring assets –
• How?
• Previous reports?
• Business?
• Suppliers?
• Quick question capture
• Examples of common recurring assets
• Databases!
• Hypervisor
• DMZ firewall
• Core switch
What about those in between bits?
Testing the overlaps..
• Red team assessments and STAR (Simulated Target Attack & Response)
• The tests replicate the tactics, techniques and procedures of threat actors that
are perceived as posing a significant threat to organisations.
Security testing third party suppliers..
Approaching them…
• Are they capable as they say they are?
• Are they doing what they say they are?
• Is my exposure what I expect it to be?
• Can I detect misuse?
• What does it actually say in the contract?
Working with testing suppliers..
Getting the best out of them…
• Define project pipeline and BAU structure in
advance.
• Define when and what resource is required and
what skills sets.
• Look to learn from their approach and scoping
methods – if in doubt, ask.. Challenge on why
things are in scope or out of scope.
• Suppliers do not know your environment or your
organisation so are making educated assumptions.
• Ask them to advise on what services to mix and
match to give value – we are not all salesmen.
In reality? Closing statement..
Is this the real life? Is this just fantasy?
• You own the risk.
• There is not a one size that fits all solution.
• We now have to be more mature.
• We need to embed security even more – change
control, project layers.
• People need to understand that it is not a box
ticking exercise.
• Define project pipeline to understand requirements
early on.
• Review BAU to determine regularity and scope of
security testing – risk profiling and management is
not scary!
Questions…
Europe
Manchester - Head Office
Cheltenham
Edinburgh
Leatherhead
London
Milton Keynes
Amsterdam
Munich
Zurich
North America
Atlanta
Austin
Chicago
Mountain View
New York
San Francisco
Seattle
Australia
Sydney
Recommended