Scoping a web application security assessment

Some tips below for scoping security assessments of web applications:

*If its a small web application and its an authenticated black box assessment, a brief understanding of the application's functionality (i.e. business logic )and the number of pages and fields will be enough to scope it. As the application is small you just test everything with full coverage. Testing to pre-defined holistic criteria aligned to key security controls is the best way to get the coverage over the vast array of vulnerabilities that result from failure of these key controls.

* If the application is large and complex then you will need to take a risk based sample based approach. If it is say a banking application you may need to test everything, If its a less risky application you may be able to test a sample of functions and a sample of fields in these functions.

* The approach I take in scoping large complex web applications is along these lines:

- conduct a risk assessment, identify the key threats to confidentiality, integrity and availability and the functions that an attacker would need to abuse to do this, (think parameter manipulation )and the key controls accross the application (e.g. Authentication, session management and input validation) that prevent such attacks. You will need information such as architecture documentation, application use cases etc. to understand the application in order to risk assess it.

- The next step is to write a test plan so that stakeholders know what the approach is to testing, what will be covered and what will not. The test plan should also outline what test data and test environments are required. On big projects it is also important to stage testing in line with the application's development so all defects are not identified at the last minute with no time to remediate before go live. The integration of static code analysis during the development should be considered and complemented with manual targeted web application testing of key controls. (i.e. Use SCA to test if input validation function applied to all fields correctly and then manually test the input validation function for vulnerabilities).

- After the test plan has been written, then you can accurately scope the assessment in terms of effort and hence cost.

Thoughts on David Rice and understanding the infosec customer

David Rice of "geekonomics - the true cost of insecure software" fame just did a keynote at the govcert conference expousing the benefits of understanding the security industry's customers .
He shared some very valid thoughts with us, namely:

* There is no one size fits all "platonic ideal" of a security program. Each organisation has a different risk profile and risk appettite and requires a different approach. There is no one perfect security programs but perhaps there are many perfect security programs.

* By understanding who are "customers " are and by conducting detailed analysis of our "customers" wants/needs/buying process etc. as an industry we can develop tailored "products" for them. By products I mean legislation, regulation, standards, blueprints, technical protocols etc.

* This will help the security industry mature and better meet the needs of its customers and identify untapped pockets of growth.

If I was going to start doing some "horizontal segmentation market research" for the security industry some of the market segments I would be likely to identify would be:

CONSUMER

Internet Connected Pensioner
Mum and Dad
Gen X slacker
Hyperconnected Gen Y

SME

Risk unaware one man band
Risk adverse One man band
Risk embracing One man band
Risk embracing growing young company

Risk adverse static small business

ENTERPRISE

Infosec manager
Undertrained Infosec analyst
IT project manager
Risk adverse Business line manager
Risk embracing Business Executive
Overstressed IT Operations manager
IT nerd

GOVERNMENT

Law/Business background legislator
Cybersecurity Czar
Technocrat

By analysing the wants and needs of these market segments in more detail perhaps we may be able to;

* identify legislation that matches the risk profile and risk appettite of the organisation and the market segment

* package up security policy, procedure and technology suitable for market segments that is actually attractive to the end users (perhaps from a fear sell to a greed sell to coin Schnier) and is not what we think they want but what they really want.

* Develop "marketing approaches" that resonate with the customer and educate rather than FUD and hoodwink tactics. E.g. Address legislators valid concerns about child protection online with actually effective approaches

great interview with shipley on risky business re soupnazi

There was a fantastic interview with Greg Shipley in the latest risky.biz podcast #126 . Quick recap below:
*Pretty much Lots of large corporates got owned, over 100M credit cards stolen. Why did this happen?

*Base assumptions were made on effectiveness of control technologies by C suite i.e. we passed PCI-DSS, have firewalls, vulnerability assessment, IDS and antivirus hence we are safe.

*Shipley recommends the use of information risk register in IT function and application of compensating controls when security controls not effective

*IT can't convey technical risk effectively to management .

*Most organisations haven't mapped critical processes to data sets to systems and supporting infrastructure so additional controls such as network segregation and increased monitoring can be applied.

*until CEO knows what questions to ask CIO to identify if corporate data is safe we still have a problem.

I had some thoughts on the control technologies mentioned:

*firewalls - holes are punched through the firewalls to allow access to the applications that contain the critical data (e.g. Http to web app server, from web server to app server from app server to db server.) Hence security reliant on the controls implemented in these interfaces and any unpatched and 0day vulnerabilities (e.g. Input validation in web app, method of database connection, database listener patching)

*vulnerability assessment - vulnerability assessment is only effective if the vulnerabilities identified are actioned. In most organisations getting traction on better patch management and comfiguration management is an uphill battle without a clear business case and executive support.

*IDS - IDS has to be correctly placed so that traffic can be sniffed (i.e after where SSL tunnel terminates). Most organisations have NIDS only that is badly placed, badly tuned and non-monitored.

*audit logs - audit logs only detect usage of legitimate functions usually by authorised users, not OS compromise. Also once server compromised logs can be wiped if not centralised on a secure server.

*anti-virus - only detects variants of known families of remote access trojans does not detect custom crimeware much of which now is written and tested to avoid AV.

*PCI-DSS - no matter how gun your QSA is, it is only a point in time assessment and the QSA is an outsider unfamiliar with your environment. If actually performing the audit procedures required, (rather than a chat and issuance of a report as is rumoured to occurr ) He/She will check you do not have plaintext cardholder data in your database . You however can turn on diagnostics 5mins after they leave to troubleshoot an issue, forget about it and next thing you know there are half a million PANs in a text file easy pickings for anyone who cranks up metasploit (and has access to the network)

My thoughts on questions for CEO to ask CIO:?

*what % of IT budget is allocated to infosec ?

*do we know what our critical business processes, information assets, applications and supporting infrastructure are?

*of these critical applications and infrastructure, are we testing the protective security controls and are they effective in reducing the inherent risk to a level I would be happy with?

*are there additional trustworthy detective controls such as integrity monitoring on these systems (i.e tripwire is the bomb)

High level application security requirements

Hey ISO wouldn't it be handy to have a set of high level security requirements for business applications, with a list of security controls maybe on a sliding scale based on the risk of the application ? I propose the following for the high level categories (can't have too many so have consolidated similar ones):
-secure authentication and session management
-secure authorisation and access control
-data canonicalisation known good input validation and sanitisation for storage and output
- logging, monitoring and reporting
- interface authentication and encryption
- data at rest encryption and database security

Maybe I should have a look at orange book/common criteria etc. ?

Criteria for evaluating a cloud services provider

Was having some ideas about how cloud services providers could turn their investment in security into a compettitive advantage. For this to be accomplished there needs to be a frame of reference established.

So here are a few criteria for evaluation of SAAS vendors as a series of questions:
* have security requirements from legislation (e.g. Privacy act), regulation (e.g. PCI-DSS )and relevant best practice (e.g. ISO 27002 )been recorded?
*has a security architecture been developed, that considers both application and hosting infrastructure?
*does the application security architecture leverage the security functionality available in the application development framework?
*have security controls been tested functionally?
*has static code analysis for common security vulnerabilities been performed?
*has security functionality in framework been implemented?
*have security controls been tested for vulnerabilities by a qualified 3rd party?
*are release, change and configuration management processes in place?

Information security function governance maturity

I've observed the following evolution from information security functions over the years as they grow in maturity. I've represented this evolution in maturity below in a series of statements, paraphrased from many discussions from many organisations. Keen to get people's feedback, and more submissions of similar statements and where they fit in the order below.

1. "What do you mean ? We've got security we have a firewall and antivirus?"

2. "So we have to comply with (insert compliance requirement here)? Well we better write a security policy on that"

3. "Gee we have a lot of compliance requirements now. We better start tracking them in a compliance requirement register so they get put in the policy".

4. That security incident wouldn't have occurred if people comply with the damn policy! How do we check they comply with the policy? Policy compliance checks that's how.

5. Hey there's a project over there, that could bring in new risks. Lets do a policy compliance check on it.

6. Hey it was good we did that compliance check there was non-compliance and new risks were being introduced. We better make a risk register to record these risks

7. No-one knows about the security policy, and they won't heed it! We better get some executive commitment in a security charter as they won't read the whole set of documents and do some security education.

7. No-one is fixing the policy non-compliances we are noting, we need to track them. Lets issue exemptions and put them in an exemption register

8. I wish all these projects would stop asking me how to comply with policy. Maybe we need an enterprise security architecture to show them what to do?

9. Its hard to translate the security policy into an enterprise security architecture, maybe we need some specific purpose standards and some guidelines?

10. Darn, that security incident occurred in an existing system/business process! Maybe we should do compliance checks on all the Business As Usual (BAU) systems?

11. AArgh! There are so many of these BAU systems! we need to record these and identify the critical ones so we can start on the most important ones first. Wish we had some asset management and data classification in place

11. Wow there's a lot of information assets, how are we going to classify all of these? Lets get someone embedded in each business unit to help us with this.

12. What about business processes, they create the information assets that go into the systems that make the systems critical. We'll do risk assessments on business processes to help us identify the critical systems!

13. Wow we've got a lot of risks in risk registers for each business unit and they are all written differently, it would be good to get an enterprise view of this. We need to build/buy a risk management system pre-populated with risk descriptions.

14. The policy and standards represents controls, maybe we should identify the key controls and test them and put the risks in the risk management system.

15. Too many spreadsheets! I wish I could standardise all this control testing, can we put that in the risk management system?

16. People are saying we say no too often and too late in the project lifecycle. How can we engage with the business better? I guess we could empower projects to set their security requirements, conduct their own risk assessments and control testing? Trust but verify! It works for Microsoft!