Plain and simple: this book is a must read if you’re either thinking about deploying ModSecurity to protect your web applications or already have a basic ModSecurity deployment and want to learn how to customize it for your environment. Because I’m already well versed with ModSecurity, I decided read this book cover to cover without the distraction of the keyboard so that I could truly focus on how well complex topics like web application firewalls (WAF) and web application security could be covered in 250 pages. After about 5 hours of reading, I had reached the appendices and spent the next 2 days working back through the rulesets I use to protect my own web properties. Not only do I feel that I now have a more secure set of rules, I have also documented the performance impacts of ModSecurity on the Apache processes and reduced the overall response time of my applications by about 6ms.
The first 2 chapters of the book deal with installing, configuring, and rule writing basics for ModSecurity 2.5 with Apache 2.x. Magnus Mischel walks the reader through installing and configuring the module in Apache and making sure the installation is working properly. The chapter assumes best case scenarios for defaults in the operating system while in my experience, ModSecurity installs rarely go that easily. That being said, the preface of the book specifies that a good understanding of system administration principles is suggested to get the most out of the book and distribution specific installation guides for ModSecurity are widely available online. Mischel then goes on to introduce the ModSecurity rule writing syntax which he very astutely presents in two sections: rule grammar and structure followed by practical examples of how to write rules to mitigate vulnerabilities. Even after spending 1.5 years running numerous production instances of ModSecurity with custom rules, Mischel’s in depth coverage of the topic still had me hunting around for my highlighter to mark sections of the chapter containing syntax features that I didn’t know existed.
The book also does a great job of covering ModSecurity performance and logging. Mischel uses httpperf to benchmark server response time, memory usage, and processor load and presents the results for Apache with/without ModSecurity and with/without the default ruleset. Readers will find that this data will be invaluable if they ever need to sell the security benefit vs. system performance degradation to system administrators and executives. The chapter on logging and auditing offers an in depth look at the features available in ModSecurity offering insight on real world log and audit needs balanced with the processing overhead associated with excessive data collection. Mischel also provides a detailed implementation guide for deploying the ModSecurity Console with mlogc giving administrators and analysts a dashboard for monitoring alerts in a environment using multiple instances of ModSecurity.
One of the chapters I was most looking forward to reading was “Blocking Common Attacks” where Mischel presents a number of common web application vulnerabilities, offers an overview of the causes and impacts of said vulnerabilities and presents a virtual patch using a series of ModSecurity rules. To be perfectly honest, I was left a little disappointed with lack of depth in some of the content. While I understand that in depth coverage of web application vulnerabilities is probably beyond the scope of the book, the additional knowledge required to fully understand the causes and exploits of the issues that are presented in this book is likely beyond the average skill set of a system administrator. I was also left a little disappointed with the section on cross site request forgeries (CSRF) which never offered any virtual patching examples to mitigate the issue. Negatives aside, Mischel does a great job at presenting ModSecurity rules for mitigating 14 types of web application vulnerabilities such as cross site scripting (XSS), sql injection (SQLi), and shell code execution.
Mischel spends an entire chapter discussing configuring ModSecurity using a positive security model tailored to a YABB (Yet Another Bulletin Board) deployment. For a veteran ModSecurity user, this was by far the best chapter in the book, even though Mischel suggest you use Ethereal (Wireshark) as your local web proxy (you should be using Burp Suite by Portswigger). I can only hope that readers who are rolling out new ModSecurity installations or who are looking to improve existing deployments read this chapter and realize the value of this approach and choose to do the same to protect their applications.
By including the full ModSecurity directive and variable reference and a detailed guide on Regular Expressions, Magnus Mischel has created a complete guide to ModSecurity that is not only a great introduction to the WAF technology, but also a great desk reference for the experienced administrator.
Title: ModSecurity 2.5
Author: Magnus Mischel
Publisher: PACKT Publishing
Front page taglines:
* Securing your Apache installation and web applications
* Prevent web application hacking with this easy-to-use guide
I’ve spent the past 3.5 years working on a team where my primary responsibilities involved “application security”. Now that this era has come to an end, I’d like to share some of the initiatives and define their successes and shortcomings. This is part 3 of 5 so please be sure to read parts 1 and 2.
Threat modeling, architecture reviews, and security consulting
Our application security program always offered a design review service. Initially this service wasn’t very well defined and simply involved a security engineer performing a review of available documentation and interviews with the development team. The outcome of this engagement was a series of recommendation and requirements for the project to implement during the development phase. As you can imagine, this approach was very subjective and lacked documentation, but formalization of the offering was put on the back burner due to the successes with the penetration testing offering.
A little over a year and a half after the application security program was defined, we started focusing on assimilating some of the industry proven approaches to threat modeling and security architecture best practices into our existing design review service. We leveraged the opportunities presented by the local OWASP chapter and were able to obtain the training in formal threat modeling approaches that we were easily able to adapt and offer as a fully documented and repeatable process. Unfortunately, my time with the team was up before we could really determine the effectiveness of this service offering. My hope was that we could use this service to not only identify deficiencies in secure design early in the lifecycle, but also to setup a plan for providing training, code review / SCA services, and penetration testing at the appropriate times. This would effectively setup a consulting relationship between the individual security engineers and the project team where a single person / team could be leveraged for all aspects of application security.
I’ve spent the past 3.5 years working on a team where my primary responsibilities involved “application security”. Now that this era has come to an end, I’d like to share some of the initiatives and define their successes and shortcomings. This is part 2 of 5 so please be sure to read part 1.
Penetration Testing
Like most application security programs, ours was started by 2 of the team members who had some understanding of the vulnerability space in applications (mostly web based) and knew how to test for them. In a company with a seemingly unlimited number of custom web applications the target space was wide and varied which provided a vast playground for exploration and learning. Over time, the value of our hacking away at these web properties coupled with a few juicy findings quickly became apparent to the leadership and we were asked to work on expanding this capability to the rest of the team while maintaining the high level of thoroughness, accuracy, and professionalism our internal customers had grown accustomed to.
We were faced with the unique challenge of defining and documenting the vulnerability space, provide documented examples of how to identify and exploit the vulnerabilities, provide in person training to explore the complexities of application architectures and the interconnectedness of various components, and provide the development background necessary to work with developers to resolve the issues. Fortunately for us, the Open Web Application Security Project (OWASP) had already published some early versions of the OWASP Testing Guide and the OWASP Development Guide. These two documents provided the written documentation necessary to begin familiarizing the team with the general concepts and jargon associated with web application security. With the help of the OWASP WebGoat tool, we were able to provide a platform on which the engineers to practice what they were learning in the documents. We also conducted some additional internal training which took and in depth look at the vulnerabilities which were most common across our specific platforms and explored the best ways to address these issues in code. After a few years of regular training and refinement of the methodology has yielded a very efficient, accurate, and repeatable security testing service. If I had to go back and do it again, I really wouldn’t change anything. The resources obtained through the OWASP organization served us well and the existing internal knowledge was sufficient to bring the rest of the team up to speed.
I also wanted to address the issue of automated scanning. We did indeed purchase a solution which we worked tirelessly to implement and customize for our needs only to find that our manual approach with a couple open source tools was performing much better than the automated solution. This was partially due to the application we were testing, we had some particularly unique extremes in size of the application to be tested, and the automated tools simply didn’t complete scans in an amount of time that we found acceptable. If I had to do it again, I would explore some more varied options for automated testing that could be better fit for the environment. I realize the importance of an automated solution to validate applications which do have strong security requirements, but that do require some level of security assurance.
I’ve spent the past 3.5 years working on a team where my primary responsibilities involved “application security”. Now that this era has come to an end, I’d like to share some of the initiatives and define their successes and shortcomings. Since this promises to be a pretty long post, I’m going to break it up into more digestible bits containing an initiative or two.
Dedicated application security team
When I was first hired on to the team, it was responsible for both security assurance (application security) and incident response. One of the first milestones which lead to the success of the program was the separation of the team into 2 groups with distinctly different areas of responsibility: one team did security assurance, the other did incident response. I credit this move as a success because when the responsibilities were shared, engineers were required to share their focus between the proactive mindset of security assurance, and the reactive mindset of incident response. Inevitably, certain engineers were more skilled in one or the other of the disciplines and the quality of service across the different offerings would be degraded at times. While the teams now had a different and separate structures and managers, the importance of information sharing wasn’t lost as the teams were already so used to collaborating as a single team.
If your company is serious about application security and the workload justifies it, I would suggest that a dedicated application security team be created to provide the expertise needed to address the unique challenges of a complete application security problem space. The charter and team responsibilities must be carefully selected, if the mission is too narrow certain critical of the supporting components in application architectures might be out of scope, while a mission that is too broad will reduce the amount of time engineers will be able to dedicate to appsec will be limited. If I had to do it over again, I would certainly narrow the scope of the team to only include application security and associated disciplines (training, threat modeling, secure design and architecture consulting, security assessments, code reviews and analysis – SCA).
With the holidays upon us, Christmas music wherever you turn, and packed shopping center parking lots, it feels like the end of the year is upon us! We all have a million and one things going on, but one in particular stands out for me this year – I’ve decided to end my (almost) 4 year tenure at Aol. It’s certainly not a decision I made lightly, after all, I have invested a lot in the company and consider the AppSec program there to be my baby and I will miss it and my co-workers most of all.
I’m starting the next step in my career on 1/4/2010 with one of the local security consulting firms and am very much looking forward to the challenges and opportunities which the new job presents.
Happy holidays to all and may the new year bring you all the love, good health, and happiness you deserve!
We’ve all heard the term “Risk acceptance” when it comes to vulnerabilities and security issues in general. Typically, the acceptance of risk instead of actually fixing the issue is due to technical limitations, lack of funding, or just plain laziness. To make things easy on the company/agency’s compliance, the acceptance of said risk is done by a high level executive in the company or a government official who is saying:
“I understand the risk, potential exposure, and impact of this security issue. With my signature, I indicate that I am making the decision to take responsibility for any adverse impact directly relating to the exploitation of the security issue.”
Obviously, this does nothing to improve the posture of the system or application in question…but the real question I’m left with is: what happens to that executive or government official when the system DOES get hacked through a vulnerability with “accepted risk”? Do they get fired? Demoted? Ordered to pay restitution losses?
Sadly, usually nothing happens. The individual continues to collect a pay check, manage employees, and accept risk for the security vulnerabilities that affect systems under their purview.
Plain and simple: this book is a must read if you’re either thinking about deploying ModSecurity to protect your web applications or already have a basic ModSecurity deployment and want to learn how to customize it for your environment. Because I’m already well versed with ModSecurity, I decided read this book cover to cover without the distraction of the keyboard so that I could truly focus on how well complex topics like web application firewalls (WAF) and web application security could be covered in 250 pages. After about 5 hours of reading, I had reached the appendices and spent the next 2 days working back through the rulesets I use to protect my own web properties. Not only do I feel that I now have a more secure set of rules, I have also documented the performance impacts of ModSecurity on the Apache processes and reduced the overall response time of my applications by about 6ms.
With the holidays upon us, Christmas music wherever you turn, and packed shopping center parking lots, it feels like the end of the year is upon us! We all have a million and one things going on, but one in particular stands out for me this year – I’ve decided to end my (almost) 4 year tenure at Aol. It’s certainly not a decision I made lightly, after all, I have invested a lot in the company and consider the AppSec program there to be my baby and I will miss it and my co-workers most of all.
We’ve all heard the term “Risk acceptance” when it comes to vulnerabilities and security issues in general. Typically, the acceptance of risk instead of actually fixing the issue is due to technical limitations, lack of funding, or just plain laziness. To make things easy on the company/agency’s compliance, the acceptance of said risk is done by a high level executive in the company or a government official who is saying:
DandyID
Friendfeed
claimID
Disqus
Facebook
Twitter
myOpenID
Google Profiles
Linkedin