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