I absolutely love my job and one of the coolest things about what I do is getting to do proof-of-concepts with bleeding edge technology. I feel very privileged that many companies out there respect me enough to provide me with these opportunities and I feel that engaging on this level enables me to be a better security practitioner because I routinely have my finger on the pulse of the latest and greatest tools out there. The problem that I run into, however, is when vendors present me "enterprise ready" tools that are clearly not enterprise ready. Maybe it's a cool concept, a working prototype, or even a functional system. The problem is that "enterprise ready" assumes so much more than just a product that does some stuff as advertised. To me, at least, it assumes a product that can be easily transitioned to the company's IT team for long-term support of the platform. Here are some signs to look out for that will tell you if the tool is truly ready for the big show:
- Installation Process: This one could honestly go either way. Personally, I prefer to have a product that I can install and configure myself. I cringe every time I hear a vendor mention to me that professional services are involved in an installation. I get it, sometimes a tool is so highly customized to your environment that you need help, but the majority of the products I use on a daily basis aren't that way. If installing a product requires a day of professional services time, then this should probably be your first signal to at least start looking out for the following additional signs.
- Initialization Script: I honestly feel a bit silly even having to mention this as I would assume this to be a standard part of any enterprise product, but it's not. If I have to poke around in the installation directory looking for the right script to run to start or stop your product, then it's not enterprise ready. Even worse, if it's a more complex product that requires starting multiple pieces and you don't have a single init script to handle the startup and shutdown in the proper order, then your product is not enterprise ready. If you're trying to sell me something to make my life as a security professional easier, then I should spend my time using your tool instead of figuring out how to start and stop it.
- Release Notifications: If I buy a product from you and I'm paying you for support, then, I'm typically doing so with the intention that I will be able to move to the next version once it is released. Maybe it's because there are bugs that need to be fix or because there is new functionality, but whatever the reason, I want to know when that version becomes available. I'll talk a bit more about the upgrade process itself in the next bullet, but if the company does not have a way to notify you when a new release is available, be wary.
- Defined Upgrade Process: Have you ever used a tool that you thought was completely awesome until the first time that an upgrade rolled around? They tell you copy these files over and it breaks. Now, run this script and it fails. You engage support and spend hours on the phone with them and then a week later they offer a webex where a support person will take care of the upgrade for you. I had to ditch a really interesting tool a while back for this very reason and I'm currently dealing with another one where every upgrade requires a support person to come onsite. It's a completely ineffective use of both my time and theirs. When I designed SimpleRisk, one of the first things I considered was how to make it as simple as possible for a remote person to upgrade the tool without assistance. I've at least got it down to copying some files and running a script which anyone can do. Even better are the companies where it's click a button to upgrade. Better still are the companies that just automatically do the upgrade for you. In any case, be wary of any upgrade processes that are not well-defined.
- Backup Plan: This may not apply to all products or all scenarios, but it's a good idea when evaluating a product to ask yourself how you will back up the data and recover it if a disaster ever strikes. If the answer is "We'd just wipe and reinstall", then cool, but if the answer is "F*ck, I don't know", it may be worth having that discussion with the vendor.
- Monitoring: Nothing bothers me more than when I'm all excited to use my shiny new toy and when I go to log in it's down. In reality, I should know it's down when it happens because there's a high likelihood that the tool isn't doing what it's supposed to if it's not running. Ask your vendor what you should be monitoring in order to ensure that the tool is functioning properly. If they don't have a good answer for you, be wary.
- Product Roadmap: When you purchase a product, you purchase it not only for what it's capable of doing for you today, but also for the opportunities that it will provide you with tomorrow. Ask the vendor about their product roadmap to see if it's in-line with your vision of how you intend to use the product. Are there features that you can use down the line? More importantly, do they have plans to continue to invest in the platform that they are selling you or is it just major bug fixes at this point while they move on to something else. If the vendor can't give you a straight answer to this question, then you may have problems.
Don't get me wrong. There are plenty of tools out there that fail one or more of these signs and that doesn't mean that you should completely avoid them, but you shouldn't expect to pay a premium for them either. Hopefully the vendor is being honest with themselves and labeling it as "Beta" while they work to iron these things out. If not, you should be honest with them about your willingness to accept a product that is not "enterprise ready". Perhaps you're willing to accept a little bit of pain for a smaller price tag. Maybe you want to be able to brag to your peers that you were the first to have that product hotness. Whatever the reason, just make sure that you are aware of what you're getting into up front.
The first presentation of the day that I went to was by GE's Darren Challey and was about GE's application security program and how he took a holistic approach to securing the enterprise. My notes on this presentation are below:
Why is AppSec so hard?
- AppSec changes rapidly (look at difference between 2004, 2007, and 2010 Top 10)
- Changing landscape
- Increase skill and talen t pool of technically proficient individuals willing to break the law
- Growing volume of financially valuable data online
- Development of criminal markets (black markets) to facilitate conversion to money
- "Attackers now have effective skills, something to steal, and a place to sell it"
- Application Security is a complete one-sided game
- Need to become an enabler (not a barrier)
- Must inject application security earlier through Guidance, Education, and Tools
- Must understand the development and deployment process and integrate rather than mandate
- NIST study on cost to repair defects when found at different stages of software development (http://www.nist.gov/director/prog-ofc/report02-3.pdf)
- Solving the problem of the enterprise (Culture Change)
- Success factors
- Form a mission and strategy
- Develop policy (but not corporate "mandate")
- Gain executive buy-in (cost / benefit / risk)
- Understand the magnitude of problem (metrics)
- Asset inventory and vulnerability management
- Develop standards (what should I do and when?)
- Establish a formal program (strong leadership)
- Focus on education and training materials
- Develop in-house expertise, services and "COE"
- Continuous improvement, measurement, KPI
- Drive a culture change (shared need, WIIFM)
- Communicate expectations with vendors
- Implement incentives (and penalties)
- Digitize after the process is solid (tools)
- AppSec program mission & structure
- AppSec program strategy
- Policy (guidance) -> Standards (Guidance) -> Training (Education) -> Metrics (tools) -> Security tools (tools) -> Inventory & tracking (tools) -> Monitor & Improve
- "GE Application Security Working Group" (Talking to the businesses is critical! Meet every 2 weeks.)
- Secure Coding Guidelines
- Vulnerability Remediation Guide
- Secure Deployment
- Quick Reference Card
- Contractual Language
- Desk Calendars
- Metrics: AppSec calendars helped increase visitors to key Guidance materials (track hits to website docs when certain activities take place)
- CBT1: Intro to AppSec at GE (60 min for any IT person) - why AppSec is important and what happens when you don't do it
- CBT2: GE Best Practices for Secure Coding (90 min)
- CBT3: Attack Profiles & Countermeasures (120 min for security people)
- Developer Awareness Assessment:
- 100's of internally-developed questions
- Randomized questions, timed completion
- Vendors track their own resutls
- Allows tailoring of training/awareness programs
- - COE AppSec assessment services
- Vendor framework & Metrics
- Compliance handbook
- Common objects repository
- GE Enterprise Application Security
- Scanning and Monitoring tools
- Automation is the way to go (but the tools are not quite there yet)
- Measure Vendor AppSec Performance (Avg % Critical/High Vulnerabilities per Assessment vs % Assessments with Zero Critical/High Vulnerabilities)
- Is it making a difference (map avg of critical/high vulnerabilities per assessment)
Forming a Center of Excellence
- Combines the best available people, processes and tools
- Formal training & defined roles (Comprehensive training program for all auditors to ensure skills are kept current and that auditors can provide more than one type of service)
- COE Team structure (tools, research, operations, stakeholder management, queue management, application security auditors
- Application Assessment Types (black/grey box vs white box)
- Application assessment process (map of the workflow with "swim lanes" of who does each step)
- Measure number of vulnerabilities and severities
- Measure customer satisfaction (overall, ease of engagement, responsiveness)
This presentation was by Jeff Williams, OWASP Chair, on the Enterprise Security API.
Vulnerabilities and Security Controls
- Missing - 35%
- Broken - 30%
- Ignored - 20%
- Misused - 15%
Goal is to enable developers. Need to give them hands-on training, a secure coding guideline, and an Enterprise Security API.
The problem with Security Libraries: overpowerful, incomplete, not integrated, broken, can't update, custom.
Enterprise Security API (ESAPI) includes authentication, user, AccessController, AccessReferenceMap, Validator, ENcoder, HTTPUtilities, Encryptor, EncryptedProperties, Randomizer, Exception Handling, Logger, IntrusionDetection, and SecurityConfiguration. Built on top of your existing enterprise services or libraries.
- Input Validation - validation engine and decoding engine that will take input and provide safe output for web pages
- Output Encoding - need to use the right encoding for the right place you are putting the encoding
- Authentication - creates a user object and functions to login() or logout(). Provides additional functionality for encrypted cookies, changing SESSIONID, remember me cookies, etc.
- Access Control - provides functionality to check if a user is authorized for URLs, functions, data, services, or files.
- Direct Object Reference Protection - use an access reference map that does an indirect translation between an object and it's reference. Use getDirectReference() and getIndirectReference() functions.
- Error, Logging, and Detection - Configurable thresholds. Responses are log intrusion, logout user, and disable account. User object is available anywhere in the application so the logger links the messages logged to a user. Exceptions sent to an intrusion detector which has thresholds set.
OWASP ESAPI Covers Majority of OWASP Top Ten
- A1. XSS - Validator, Encoder
- A2. Injection Flaws - Encoder
- A3. Malicious File Execution - HTTPUtilities (Safe Upload)
- A4. Insecure Direct Object Reference - AccessReferenceMap, AccessController
- A5. CSRF - User (CSRF TOken)
- A6. Leakage and Improper Error Handling - EnterpriseSecurityException, HTTPUtils
- A7. Broken Authenticationa nd Sessions - Authenticator, User, HTTPUtils
- A8. Insecure Cryptographic Storage - Encryptor
- A9. Insecure Communications - HTTPUtilities (Secure Cookie, Channel)
- A10. Failure to Restrict URL Access - AccessController
MITRE found that all application security tool vendors' claims put together cover only 45% of the known vulnerability types (695). They found very little overlap between tools, so to get 45% you need them all (assuming their claims are true). This means that at least 55% is not covered by tools.
Latest version released in September 2008 (1.3.1) and are holding a summit later this year to determine if they got everything right. In active development. Java, .NET, PHP, classic ASP. Rich client extensions. Web service extensions. Framework (Struts) integration.
Written under the BSD license so it should be very easy for you to use it in your applciations.
Project Home Page: http://www.owasp.org/index.php/ESAPI
Expert advisory/design/implementation team that has collectively reviewed over 100 million lines of code. ~600 JUnit test cases. FindBugs, PMD, Ounce, and Fortify clean. Code review by several Java security experts. Penetration test of sample applications. Full Javadoc for all functions.
Presentation will be posted on homepage. Includes a list of banned API's that ESAPI replaces. Has example of enterprise cost savings. All of ESAPI is only 5000 lines of code. Building a ESAPI swingset which has a demo of insecure (what can go wrong) and secure (using ESAPI) programming and good tutorial on how to use. Login module shows last successful login, last failed login, number of failed logins, enforces a strong password policy.