A stitch in time....
Our Traditional approach to penetration testing, even large scale global penetration testing is to perform an annual/bi-annual pen test on our web applications.
Question is who said once a year is enough?
Most applications undergo at least quarterly updates and changes if not to provide value for customers but to ensure the web applications are fresh and to address any (hopefully) minor bugs.
Cyber attackers can perform a continuous scan on your site to detect changes (code drops) and probe such changes to assess if any vulnerability has been introduced.
Why do we think it is acceptable to perform a time-limited test of an application to help ensure security when a determined attacker may spend 10-100 times longer attempting to find a suitable vulnerability.
The main reasons for a one-off test per year are simply economics:
Russian Cyber Crime Figures –$4.5 billion (2011)
Euro Zone Cyber Crime - €750 billion (2011)
Question is who said once a year is enough?
Most applications undergo at least quarterly updates and changes if not to provide value for customers but to ensure the web applications are fresh and to address any (hopefully) minor bugs.
Cyber attackers can perform a continuous scan on your site to detect changes (code drops) and probe such changes to assess if any vulnerability has been introduced.
Why do we think it is acceptable to perform a time-limited test of an application to help ensure security when a determined attacker may spend 10-100 times longer attempting to find a suitable vulnerability.
The main reasons for a one-off test per year are simply economics:
- Testing takes resources
- Resources cost money
- Resources are scarce
- Push to deploy is stronger than push to secure
- Organisations feel they may be left alone
- A one-off annual test ticks the compliance box
Russian Cyber Crime Figures –$4.5 billion (2011)
Euro Zone Cyber Crime - €750 billion (2011)
UK - £43.5 billion – 2011
I see a trend in continuous monitoring, what does this mean?
Using systems that continually spider/crawl and assess a web application, compare it to the last sweep and detect changes in the target.
Changes detected are assessed for any potential introduction of new vulnerabilities and risk.
Changes detected can be correlated with changes to the site: Code-drops, malware injection, unauthorised deployments, scheduled maintenance.
Scanning alone wont work:
Continuous monitoring also requires manual validation of all discovered issues or "grey issues" which require further assessment. The benefit is the engine "learns" over the years how the site is structured and tailors its testing methodology and result parsing to that particular site.
A continuous monitoring engine may also be an "expert" system; it uses its feedback and manual tuning to learn how to assess more accurately as it assesses. As the engine accuracy increases the manual intervention in some cases will decrease.
There is one area which is a hard nut to crack. This is the area of business logic security testing. Testing applications from a business logic and role based authorisation standpoint can be difficult for a machine to figure out. The majority of such testing requires knowledge of the business flow and also the context of the data. Some systems for example may appear to have a CSRF (Cross Site Request Forgery) vulnerability but in reality the application do not perform straight-thru processing, a person checks all submitted transaction requests.
Develop in a secure manner:
Another activity which can take some of the heat off is secure application development.
Many of the worlds larger organisations that developer awareness and training are some of the most cost effective methods to assist with developing secure software.
Teach developers about secure API's, Client and server side threats.
Get Serious...
Also tell executives of the potential sanctions if they fail to meet data protection requirements!!
EU directive:
http://register.consilium.europa.eu/pdf/en/12/st05/st05853.en12.pdf
Article 23,24 & 79, - Administrative sanctions
Threat modelling is also very powerful; Decomposing a software design into components and looking at an application from an Abuse, Misuse and Negative use-case standpoint. Understanding trust boundaries and areas in the application which either hold or invoke/process significant data within the application.
This can be a high level or as low as you want, but when use cases are agreed within the team which could result in a security issue the technical team understand why a particular security control needs to be implemented.
There should be a more cost effective and reasonable solution which could at least raise-the-bar for web application security.
I see a trend in continuous monitoring, what does this mean?
Using systems that continually spider/crawl and assess a web application, compare it to the last sweep and detect changes in the target.
Changes detected are assessed for any potential introduction of new vulnerabilities and risk.
Changes detected can be correlated with changes to the site: Code-drops, malware injection, unauthorised deployments, scheduled maintenance.
Scanning alone wont work:
Continuous monitoring also requires manual validation of all discovered issues or "grey issues" which require further assessment. The benefit is the engine "learns" over the years how the site is structured and tailors its testing methodology and result parsing to that particular site.
A continuous monitoring engine may also be an "expert" system; it uses its feedback and manual tuning to learn how to assess more accurately as it assesses. As the engine accuracy increases the manual intervention in some cases will decrease.
There is one area which is a hard nut to crack. This is the area of business logic security testing. Testing applications from a business logic and role based authorisation standpoint can be difficult for a machine to figure out. The majority of such testing requires knowledge of the business flow and also the context of the data. Some systems for example may appear to have a CSRF (Cross Site Request Forgery) vulnerability but in reality the application do not perform straight-thru processing, a person checks all submitted transaction requests.
Develop in a secure manner:
Another activity which can take some of the heat off is secure application development.
Many of the worlds larger organisations that developer awareness and training are some of the most cost effective methods to assist with developing secure software.
Teach developers about secure API's, Client and server side threats.
Get Serious...
Also tell executives of the potential sanctions if they fail to meet data protection requirements!!
EU directive:
http://register.consilium.europa.eu/pdf/en/12/st05/st05853.en12.pdf
“The supervisory authority shall impose a fine up to 250 000 EUR, or in case of an enterprise up to 0.5 % of its annual worldwide turnover, to anyone who, intentionally or negligently does not protect personal data”
Threat modelling is also very powerful; Decomposing a software design into components and looking at an application from an Abuse, Misuse and Negative use-case standpoint. Understanding trust boundaries and areas in the application which either hold or invoke/process significant data within the application.
This can be a high level or as low as you want, but when use cases are agreed within the team which could result in a security issue the technical team understand why a particular security control needs to be implemented.
Comments
Post a Comment