Developing Security

Defense in the Deep End

Let's say I had a hypothetical large scale environment to secure with an unlimited budget. I could choose any form of countermeasures I wanted, provided that nothing I purchased remained unused. How would I choose to apply defense in depth?

When defining the required compensating controls for threat management, context is important. URL filtration isn't very exciting for a server that no one logs on to. Neither is database activity monitoring for the PC's in my call center, or a WAF for a sales person's laptop.

In addition to ensuring that the technology fits the role, it also has to provide a complimentary 'threat funnel' with little overlap. Each piece of the puzzle would have to provide some form of value against external or internal threats.

Here are the technologies I would deploy and where:

	Perimeter	Desktops	Laptops	Servers
Firewall
Network Anti-Malware (HTTP, SMTP, etc.)
File-Based Anti-Malware
Network IDS/IPS
System IDS/IPS
Anti-Spam				(On Mail Servers)
Anti-Phishing
URL Filtering & Web Threat Protection
Hard Drive Encryption
VPN
WAF				or (On Web Servers)
DLP
System/Application Log Forwarding (To SI/EM)
File Integrity Monitoring
DAM and Database Security				(On Database Servers)
Directory Integrity Monitoring				(On Directory Servers)

You'll likely see a few things missing (most notably NAC). Working within my no-shelfware condition I would likely have to pass on several technologies that are too hard to deploy, manage, or provide niche protection.

I would want to manage carefully the balance between best-in-breed and vendor sprawl. Ideally all of these functions could be accomplished by 2-3 vendors and in all cases reporting back to my SI/EM. I would compliment these point products with vulnerability scanning, risk management, patch management, event correlation and change control.

The problem is, no one has a fantasy budget of unlimited money and more importantly, time to assess, configure and monitor all of the controls they really need. Defense in depth is complicated, expensive and does require a very diverse feature mix. We are constrained, unable to create our dream suite of protection.

When it comes to enterprise threat management, I can't help but feel we are in over our heads.

 

Authentication and the art of the Error Message

On the first authentication system that I ever wrote I made an innocent mistake that, thankfully, was exposed by QA. The authentication error message when an account was locked out was slightly different depending if the entered password was correct or incorrect. The vulnerability there was that a brute force attempt could cycle through all of the passwords until it found the right one. The lockout would have engaged but the attacker could simply wait for the account to be unlocked. In my defense I was trying to give the user as much information about the source of their denied access as possible.

This really made me examine the whole issue of the authentication error message. The most secure thing would simply be to error with "Invalid" for any circumstance. This would prevent any brute force attempt from gaining any information whatsoever. This however, would be a serious usability issue resulting in frustrated users making unneeded password resets or help desk calls. There is a healthy balance though, between the two extremes. For instance the 28 potential error messages in Sun Java System Access Manager give away WAY too much information that, while appreciated by a user, can be abused by a brute force script.

So in the authentication error message we have a clear case of compromising security for usability.

In my opinion the following three error messages are the only error messages that should be provided to the user for a secure authentication system:

"Incorrect Username and/or Password"

This error lets the user know they have failed authentication without giving away the source of the mistake. It could be an unknown account or it could be a known account with an incorrect password. It's important that that the message not be different when the account is unknown. This is also the error message to use if the username or password does not pass validation (null, length, invalid characters) as we don't want to provide a method for a brute force script to understand what we consider valid looking usernames and passwords, thereby narrowing the search space.

"The requested account is locked out, please contact support"

Informing the user of a lockout has to be done to be usable. After all, we can't have the user keep trying forever :) Lockout too is a necessary feature to prevent brute forcing. This could be a permanent lockout or a time-based lockout to slow the attempt to brute force. The lockout is typically enacted after 3-5 failed authentication attempts. Assuming the error message is neutral after the lock out, this effectively prevents brute forcing of the passwords. But there is also the issue of brute forcing the username. The authentication system should simulate the lockout of usernames it does not know as well. This isn't very complex and can be accomplished by retaining an in-memory map of unknown user names to attempts (which can be limited in size to prevent memory DoS attack).

"An error occurred, please contact support"

This is another usability concession. If we really can't perform authentication we need to let the users know that something has to be done. This should only be for situations where the issue can be corrected (like connectivity to the database, directory or SSO), not for exceptions based on the input (like length, invalid characters or an invalid request) since again, we would give away information on what we would consider valid looking input for the username and password.

Other errors can be presented to the user if the authentication is correct and the account is not locked out. These don't present a security risk since the authentication is valid and the reason for the failure is circumstantial:

• The maximum number of concurrent sessions are in progress
• Cookies must be enabled
• Unable to redirect
• and others...
  

It's also important that no additional insight should be able to be gained by a brute force script by looking at the response (webservice, html, etc). For instance, error codes and raw exceptions are a big no-no. This is particularly a problem in API's like a Webservice, where it may be Internet-exposed and convenient to pass on raw errors. If the underlying authentication gives more detail it has to be wrapped in a generic error to hide the details.

For administrators of the authentication system, much more information on the reasons for the invalid authentication can be logged for further review as long as this information is stored and accessed securely (out of band). The detailed breakdown is important if they are truly trying to diagnose an issue with the authentication system.

While, as programmers, we want to give the user as much information as possible, it's vital to know when to be deliberately obscure.

Top 10 Required 'Abilities' of Enterprise Security Software

When working on my companies' flagship product Deep Security, every new feature requires significant planning. Unlike consumer grade security software or non-commercial packages (like our own open source product OSSEC), each new addition has a regiment of requirements to make it enterprise grade. For every feature, and indeed every line of code we add, we need to consider audit-ability, access control, API support, scalability, internationalization, and dozens of other issues unique to the enterprise environment. I have broken this down to 10 core 'abilities' that are required of enterprise quality security software in addition to the security services they provide. While this list was developed in relation to our server defense product, I think the tenets apply to all enterprise security products.

Deployability
In order to weave into the fabric of an enterprise, a security solution needs to be easily deployable. Good enterprise security software should minimize prerequisites, require the least amount of infrastructure or infrastructure change, and support a wide range of platforms (when applicable). Solutions requiring week-long installations, three or more tiers of components or specialized hardware will only deter trials and wide spread roll-out.

Configurability
The initial capability to tune a system to each environment is critical. Out-of-the-box policies help but having the tools, documentation and content to create the right policy for the systems being protected is critical. Depth of configurability is important as well, but not at the expense of usability. It's best to follow the policy of "Make the common easy, and the complex possible".

Tractability
Related to configurability, tractability ensures that the ongoing day to day management of the software is as efficient as possible. Time is money and the administrators of the system need to be able to complete routine maintenance, like content updates and policy changes, in the most expeditious way possible. Audit-ability is an important part of tractability, letting multiple administrators rapidly make changes that can be corrected and understood when undesirable outcomes ensue. Automation is another key part of tractability. Where possible, automation of processes like updates or discovery ensures that timely protection can be provided. If the system is easily managed and governed it reduces the overhead, both real and perceived, making it a daily part of security operations rather than a piece of shelf-ware.

Visibility
Notifications, reporting of events, is an essential part of any compensating control. Notifications serve to alert analysts of areas requiring immediate attention, while the reporting should provide key metrics and visualizations to convey the big picture as well as the areas that are most important. If the analyst needs to dig deeper, access to the raw logs with appropriate tools is key to fully understand a given incident. Another important part of visibility is having measurable results that the analyst can provide to the CISO, and they in turn to the other executives. Raw numbers alone are not enough, a system has to demonstrate its value in measurable results through quality metrics.

Usability
Despite the complexity of an enterprise-grade security product, it's important that usability not be overlooked. The design of the interface can drastically impact the performance of the user and when dealing with tens of thousands of nodes, events, etc. it's important that every operation, mouse click and keyboard stroke be streamlined. The use of relevant models that users already understand should be preferred over new, possibly foreign interfaces that require documentation to learn.

Defensibility
Enterprise security products have the dual responsibility of providing security services, while themselves being secure. They need to ensure they have a strong authentication, role-based access control, secure intra-node communication, integrity on the events and much more. When security is deployed as a host-based control, it must be able to withstand attacks from malware trying to disable it or tampering with the audit to cover it's tracks. Open management ports and consoles need to be carefully guarded and the operating systems and datastores fully hardened.

Availability
Enterprise-grade compensation controls need to have layers of resiliency to ensure they continue to be effective even under extreme conditions. Stability is very important for solutions running under high load 24/7. For management consoles, the ability to fail-over to warm standbys or have redundant systems is important in the case of hardware failure. No single point should be able to affect the overall security posture of the solution. The compensating controls being provided by the solution need to perform under all environments including adverse conditions like DoS attacks, low memory, irregular content, brute force attempts, etc.

Scalability
Regardless of the type of system (appliance, virtual appliance, host-based), scalability and performance is key. No matter of the type of data being processed or the number of nodes, the system needs a cost effective way to scale. If the answer to scalability is deploying more appliances or management consoles without a central point of configuration and monitoring, the costs and complexity quickly escalate.

Affordability
The software itself is only part of the overall cost of a security product. Other factors such as complexity of deployment, hours of management required, computing resources and professional services have to be factored in. Focusing on the above abilities can help reduce these costs significantly. Configurability, Tractability, Visibility, and Usability help to limit the number of management hours required to deploy, configure, and keep on top of the system's output. Efficient designs for Scalability and Availability help reduce computing resources.

Extensibility
No enterprise security product is an island of its own. It's part of a fabric of compensating controls that need to be able to work with other system. Every enterprise security product should have a library of import/export formats, support for push notifications and pull-based APIs. This includes standards such as Syslog, SNMP, Webservices (both SOAP and REST), SMTP and others depending on the type of product. While this adds a non-trivial amount of overhead to development, it also adds opportunity for working with complimentary systems (SI/EMs, Vulnerability Scanners, Patch Management, etc.) and the ability to quickly roll out integrations with non-security products in the enterprise fabric (EMS, Change Control, Tickets, etc).