Research

Our last post covered two of the main technical features of an enterprise key manager: deployment and client access options. Today we will finish up with the rest of the technical features – including physical security, standards support, and a discussion of Hardware Security Modules (HSMs). Key Generation, Encryption, and Cryptographic Functions Due to their history, some key managers also offer cryptographic functions, such as: Key generation Encryption and decryption Key rotation Digital signing Key generation and rotation options are fairly common because they are important parts of the key management lifecycle; encryption and decryption are less common. If you are considering key managers that also perform cryptographic functions, you need to consider additional requirements, such as: How are keys generated and seeded? What kinds of keys and cryptographic functions are supported? (Take a look at the standards section a bit later). Performance: How many cryptographic operations of different types can be performed per second? But key generation isn’t necessarily required – assuming you only plan to use the tool to manage existing keys – perhaps in combination with separate HSMs. Physical Security and Hardening Key managers deployed as hardware appliances tend to include extensive physical security, hardening, and tamper resistance. Many of these are designed to meet government and financial industry standards. The products come in sealed enclosures designed detect attempts to open or modify them. They only include the external ports needed for core functions, without (for example) USB ports that could be used to insert malware. Most include one or more smart card ports to insert physical keys for certain administrative functions. For example, they could require two or three administrator keys to allow access to more-secure parts of the system (and yes, this means physically walking up to the key manager and inserting cards, even if the rest of administration is through a remote interface). All of these features combine to ensure that the key manager isn’t tampered with, and that data is still secure, even if the manager is physically stolen. But physical hardening isn’t always necessary – or we wouldn’t have software and virtual machine options. Those options are still very secure, and the choice all comes down to the deployment scenarios you need to support. The software and virtual appliances also include extensive security features – just nothing tied to the hardware enclosure or other specialized hardware. Anyone claiming physical security of an appliance should meet the FIPS 140-2 standard specified by the United States National Institute of Standards and Technology (NIST), or the regional equivalent. This includes requirements for both the software and hardware security of encryption tools. Encryption Standards and Platform Support As the saying goes, the wonderful thing about standards is there are so many to choose from. This is especially true in the world of encryption, which lives and breathes based on a wide array of standards. An enterprise key manager needs to handle keys from every major encryption algorithm, plus all the communications and exchange standards (and proprietary methods) to actually manage keys outside the system or service where they are stored. As a database, technically storing the keys for different standards is easy. On the other hand, supporting all the various ways of managing keys externally, for both open and proprietary products, is far more complex. And when you add in requirements to generate, rotate, or change keys, life gets even harder. Here are some of feature options for standards and platform support: Support for storing keys for all major cryptographic standards. Support for key communications standards and platforms to exchange keys, which may include a mix of proprietary implementations (e.g., a specific database platform) and open standards (e.g., the evolving Key Management Interoperability Protocol (KMIP)). Support for generating keys for common cryptographic standards. Support for rotating keys in common applications. It all comes down to having a key manager that supports the kinds of keys you need, on the types of systems that use them. System Maintenance and Deployment Features As enterprise tools, key managers need to support a basic set of core maintenance features and configuration options: Backup and Restore Losing an encryption key is worse than losing the data. When you lose the key, you effectively lose access to every version of that data that has ever been protected. And we try to avoid unencrypted copies of encrypted data, so you are likely to lose every version of the data, forever. Enterprise key managers need to handle backups and restores in an extremely secure manner. Usually this means encrypting the entire key database (including all access control & authorization rules) in backup. Additionally, backups are usually all encrypted with multiple or split keys which require more than one administrator to access or restore. Various products use different implementation strategies to handle secure incremental backups so you can back up the system regularly without destroying system performance. High Availability and Load Balancing Some key managers might only be deployed in a limited fashion, but generally these tools need to be available all the time, every time, sometimes to large volumes of traffic. Enterprise key managers should support both high availability and load balancing options to ensure they can meet demand. Another important high-availability option is key replication. This is the process of synchronizing keys across multiple key managers, sometimes in geographically separated data centers. Replication is always tricky and needs to scale effectively to avoid either loss of a key, or conflicts in case of a breakdown during rekeying or new key issuance. Hierarchical Deployments There are many situations in which you might use multiple key managers to handle keys for different application stacks or business-unit silos. Hierarchical deployment support enables you to create a “manager of managers” to enforce consistent policies across these individual-system boundaries and throughout distributed environments. For example, you might use multiple key managers in multiple data centers to generate new keys, but have those managers report back to a central master manager for auditing and reporting. Tokenization Tokenization is an

Key Manager Technical Features Due to the different paths and use cases for encryption tools, key management solutions have likewise developed along varied paths, reflecting their respective origins. Many evolved from Hardware Security Managers (HSMs), some were built from the ground up, and others are offshoots from key managers developed for a single purpose, such as full disk or email encryption. Most key managers include a common set of base features but there are broad differences in implementation, support for deployment scenarios, and additional features. The next few posts focus on technical features, followed by some on management features (such as user interface) before we conclude with the selection process. Deployment options There are three deployment options for enterprise key managers: Hardware Appliance Software Virtual Appliance Let’s spend a moment on the differences between these approaches. Hardware Appliance The first key managers were almost all appliances – most frequently offshoots of Hardware Security Modules (HSMs). HSMs are dedicated hardware tools for the management and implementation of multiple cryptographic operations, and are in wide use (especially in financial services), so key management was a natural evolution. Hardware appliances have two main advantages: Specialized processors improve security and speed up cryptographic operations. Physical hardening provides tamper resistance. Some non-HSM-based key managers also started as hardware appliances, especially due to customer demand for physical hardening. These advantages are still important for many use cases, but within the past five to ten years the market segment of users without hardening requirements has expanded and matured. Key management itself doesn’t necessarily require encryption acceleration or hardware chains of trust. Physical hardening is still important, but not mandatory in many use cases. Software Enterprise key managers can also be deployed as software applications on your own hardware. This provides more flexibility in deployment options when you don’t need additional physical security or encryption acceleration. Running the software on commodity hardware may also be cheaper. Aside from cost savings, key management deployed as software can offer more flexibility – such as multiple back-end database options, or the ability to upgrade hardware without having to replace the entire server. Of course software running on commodity server hardware is less locked down than a secure hardware appliance, but – especially running on a dedicated properly configured server – it is more than sufficiently secure for many use cases. Virtual Appliance A virtual appliance is a pre-built virtual machine. It offers some deployment advantages from both hardware appliances and software. Virtual appliances are pre-configured, so there is no need to install software components yourself. Their bundled operating systems are generally extremely locked down and tuned to support the key manager. Deployment is similar to a hardware appliance – you don’t need to build or secure a server yourself, but as a virtual machine you can deploy it as flexibly as software (assuming you have a suitable virtualization infrastructure). This is a great option for distributed or cloud environments with an adequate virtual infrastructure. That’s a taste of the various advantages and disadvantages, and we will come back to this choice again for the selection process. Client access options Whatever deployment model you choose, you need some way of getting the keys where they need to be, when they need to be there, for cryptographic operations. Remember, for this report we are always talking about using an external key manager, which means a key exchange is always required. Clients (whatever needs the key) usually need support for the following core functions fo a complete key management lifecycle: Key generation Key exchange (gaining access to the key) Additional key lifecycle functions, such as expiring or rotating a key Depending on what you are doing, you will allow or disallow these functions under different circumstances. For example you might allow key exchange for a particular application, but not allow it any other management functions (such as generation and rotation). Access is managed one of three ways, and many tools support more than one: Software agent: A dedicated agent handles the client’s side of the key functions. These are generally designed for specific use cases – such as supporting native full disk encryption, specific backup software, various database platforms, and so on. Some agents may also perform cryptographic functions to additional hardening such as wiping the key from memory after each use. Application Programming Interfaces: Many key managers are used to handle keys from custom applications. An API allows you to access key functions directly from application code. Keep in mind that APIs are not all created equal – they vary widely in platform support, programming languages supported, the simplicity or complexity of the API calls, and the functions accessible via the API. Protocol & standards support: The key manager may support a combination of proprietary and open protocols. Various encryption tools support their own protocols for key management, and like a software agent, the key manager may include support – even if it is from a different vendor. Open protocols and standards are also emerging but not in wide use yet, and may be supported. That’s it for today. The next post will dig into the rest of the core technical functions, including a look at the role of HSMs. Share:

So far we have talked about the need for Early Warning and the Early Warning Process to set the stage for the details. We started with the internal side of the equation, gaining awareness of your environment via internal data collection and baselining. This is a great beginning, but still puts you in a reactive mode. Even if you can detect an anomaly in your environment – it’s already happened and you may be too late to prevent data loss. The next step for Early Warning is to look outside your own environment to figure out what’s happening externally. Leverage external threat intelligence for a sense of current attacks, and get an idea of the patterns you should be looking for in your internal data feeds. Of course these threat feeds aren’t a fancy crystal ball that will tell you about an attack before it happens. The attack has already happened, but not to you. We have never bought the idea that you can get ahead of an attack without a time machine. But you can become aware of an attack in the wild before it’s aimed at you, to ensure you are protected against it. Types of threat intelligence There are many different types of threat intelligence, and we are likely to see more emerge as the hype machine engages. Let’s quickly review the kinds of intel at your disposal and how they can help with the Early Warning process. Threats and Malware Malware analysis is maturing rapidly, and it is becoming commonplace to quickly and thoroughly understand exactly what a malicious code sample does and how to identify it’s behavioral indicators. We described this process in details in Malware Analysis Quant. For now, suffice it to say you aren’t looking for a specific file – but rather indicators that a file did something to a device. Fortunately a number of third parties have built information services that provide data on specific pieces of malware. You can get an analysis based on a hash of the malware file, or upload a file if it hasn’t been seen before. Then the service runs the malware through a sandbox to figure out what it does, profile it, and deliver that data back to you. What do you do with indicators of compromise? Search your environment for evidence that the malware has executed in your environment. Obviously that requires a significant and intrusive search of the configuration files, executables, and registry settings on each device, which typically requires some kind of endpoint forensics agent on each device. If that kind of access is available, then malware intelligence can provide a smoking gun for identification of compromised devices. Vulnerabilities Most folks never see the feed of new vulnerabilities that show up on a weekly or daily basis. Each scanner vendor updates their products behind the scenes and uses the most current updates to figure out whether devices are vulnerable to each new attack. But the ability to detect a new attack is directly related to how often the devices get scanned. A slightly different approach involves cross-referencing threat data (which attacks are being used) with vulnerability data to identify devices at risk. For example, if weaponized malware emerges that targets a specific vulnerability, it would be extremely useful to have an integrated way to dump out a list of devices that are vulnerable to the attack. Of course you can do this manually by reading threat intelligence and then searching vulnerability scanner output to manually create a list of impacted devices, but will you? Anything that requires additional effort all too often ends up not getting done. That’s why the Early Warning System needs to be driven by a platform integrating all this intelligence, correlating it, and providing actionable information. Reputation Since its emergence as a key data source in the battle against spam, reputation data has rapidly become a component of seemingly every security control. For example, the ability to see an IP address in one of your partner networks is compromised should set off alarms, especially if that partner has a direct connection to your environment. Basically anything can (and should) have a reputation. Devices, IP addressees, URLs, and domains for starters. If you have traffic going to a known bad site, that’s a problem. If one of your devices gets a bad reputation – perhaps as a spam relay or DoS attacker – you want to know ASAP. One specialization of reputation emerging as a separate intelligence feed is botnet intelligence. These feeds track command and control traffic globally and use that information to pinpoint malware originators, botnet controllers, and other IP address and sites your devices should avoid. Integrating this kind of feed with a firewall or web filter could prevent exfiltration traffic or communications with a controller, and identify an active bot. Factoring this kind of data into the Early Warning System enables you to use evidence of bad behavior to prioritize remediation activities. Brand Usage It would be good to get a heads up if a hacktivist group targets your organization, or a band of pirates is stealing your copyrights, so a number of services have emerged to track mentions of companies on the Internet and infer deduce they are good or bad. Copyright violations, brand squatters, and all sorts of other shenanigans can be tracked and trigger alerts to your organization, hopefully before extensive damage is done. How does this help with Early Warning? If your organization is a target, you are likely to see several different attack vectors. Think of these services as providing the information to go from DEFCON 5 to DEFCON 3, which might involve tightening the thresholds on your other intelligence feeds and monitoring sources in preparation for imminent attack. Managing the Overlap With all these disparate data sources, it becomes a significant challenge to make sure you don’t getting the same alerts multiple times. Unless your organization has a money tree in the courtyard, you likely had to rob Peter to

This series has highlighted the intertwined nature of patch and configuration management. So we will wrap up by talking about leverage from using a common technology base (platform) for patching and configuration. Capabilities that can be used across both functions include: Discovery: You can’t protect an endpoint (or other device, for that matter) if you don’t know it exists. Once you get past the dashboard, the first key platform feature is discovery, which is leveraged across both patch and configuration management. The enemy of every security professional is surprise, so make sure you know about new devices as quickly as possible – including mobile devices. Asset Repository: Closely related to discovery is integration with an enterprise asset management system/CMDB to get a heads-up whenever a new device is provisioned. This is essential for monitoring and enforcement. You can learn about new devices proactively via integration or reactively via discovery – but either way, you need to know what’s out there. Dashboard: As the primary interface, this is the interaction point for the system. Using a single platform for both patch and configuration management; you will want the ability to only show certain elements, policies, and/or alerts to authorized users or groups; depending on their specific job functions. You will also want a broader cross-function view track what’s happening on an ongoing basis. With the current state of widget-based interface design, you can expect a highly customizable environment which lets each user configure what they need and how they want to see it. Alert Management: A security team is only as good as its last incident response, so alert management is critical. This allows administrators to monitor and manage policy violations which could represent a breach or failure to implement a patch. System Administration: You can expect the standard system status and administration capabilities within the platform, including user and group administration. Keep in mind that larger and more distributed environments should have some kind of role-based access control (RBAC) and hierarchical management to manage access and entitlements for a variety of administrators with varied responsibilities. Reporting: As we mentioned in our discussion of specific controls, compliance tends to fund and drive these investments, so it is necessary to document their efficacy. That applies to both patch and configuration management, and both functions should be included in reports. Look for a mixture of customizable pre-built reports and tools to facilitate ad hoc reporting – both at the specific control level and across the entire platform. Deployment Priorities Assuming you decide to use the same platform for patch and configuration management, which capability should you deploy first? Or will you go with a big bang implementation: both simultaneously? That last question was a setup. We advocate a Quick Wins approach: deploy one function first and then move on to the next. Which should go first? That depends on your buying catalyst. Here are a few catalysts which drive implementation of patch and configuration management: Breach: If you have just had a breach, you will be under tremendous pressure to fix everything now, and spend whatever is required to get it done. As fun as it can be to get a ton of shiny gear drop-shipped and throw it all out there, it’s the wrong thing to do. Patch and configuration management are operational processes, and without the right underlying processes the deployment will fail. If you traced the breach back to a failure to patch, by all means implement patch management first. Similarly, if a configuration error resulted in the loss, then start with configuration. Audit Deficiency: The same concepts apply if the catalyst was a findings document from your auditor mandating patch and/or configuration. The good news is that you have time between assessments to get projects done, so you can be much more judicious in your rollout planning. As long as everything is done (or you have a good reason if it isn’t) by your next assessment, you should be okay. All other things being equal, we tend to favor configuration management first, because configuration monitoring can alert you to compromised devices. Operational Efficiency: If the deployment is to make your operations staff more efficient, you can’t go wrong by deploying either patch or configuration first. Patch management tends to be more automated, so that’s likely a path of least resistance to quick value. But either choice will provide significant operational efficiencies. Summary And with that we wrap up this series. We have gone deeply into implementing and managing patch and configuration management – far deeper than most organizations ever need to get the technology up and running. We hope that our comprehensive approach provides all the background you need to hit the ground running. Take what you need, skip the rest, and let us know how it works. We will assemble the series into a paper over the next few weeks, so keep an eye out for the finished product, and you still have a chance to provide feedback. Just add a comment – don’t be bashful! Share:

A few weeks ago I was out in California, transferring large sums of my personal financial worth to a large rodent. This was the third time in about as many years I engaged in this activity – spending a chunk of my young children’s college fund on churros, overpriced hotel rooms, and tickets for the privilege of walking in large crowds to stand in endless lines. As a skeptical sort of fellow, I couldn’t help but ask myself why the entire experience makes me So. Darn. Happy. Every. Single. Time. When you have been working in security for a while you tend to become highly attuned to the onslaught of constant manipulation so endemic to our society. The constant branding, marketing lies, and subtle (and not-so-subtle) abuse of psychological cues to separate you from every penny you can borrow on non-existent assets – at least that’s how it works here in Arizona. When I walk into a Disney park I know they fill the front with overpriced balloons, time the parades and events to distribute the crowd, and conveniently offer a small token of every small experience, all shippable to your home for a minor fee. Even with that knowledge, I honestly don’t give a crap and surrender myself to the experience. This begs the question: why don’t I get as angry with Disney as I do with the FUD from security vendors? It certainly isn’t due to the smiles of my children – I have been enjoying these parks since before I even conceived (get it?) of having kids. And it isn’t just Disney – I also tend to disable the skepticnator for Jimmy Buffett, New Zealand, and a few (very few) other aspects of life. The answer comes down to one word: value. Those balloons? We bought one once… and the damn thing didn’t lose a mole of helium molecules over the 5 days we had it before giving it away to some incoming kid while departing our hotel. I think her parents hate us now. As expensive as Disney is, the parks (and much of the rest of the organization) fully deliver value for dollar. You might not agree, but that isn’t my problem. The parks are the best maintained in the business. The attention to detail goes beyond nearly anything you see anywhere else. For example, at Disneyland they update the Haunted Mansion with a whole Nightmare Before Christmas theme. They don’t merely add some external decorations and window dressing – they literally replace the animatronics inside the ride between Halloween and Christmas. It’s an entirely different experience. Hop on Netflix and compare the animation from nearly any other kids channel to the Disney stuff – there is a very visible quality difference. If you have a kid of the right age, there is no shortage of free games on the website. Download the Watch Disney app for your iDevice and they not only rotate the free shows, but they often fill it with some of the latest episodes and the holiday ones kids go nuts for. I am not saying they get everything right, but overall you get what you pay for, even if it costs more than some of the competition. And I fully understand that it’s a cash extraction machine. Buffett is the same way: I have never been to a bad concert, and even if his branded beer and tequila are crap, I get a lot of enjoyment value for each dollar I pay. Even after I sober up. It seems not many companies offer this sort of value. For example, I quite like my Ford but it is crystal clear that dealerships ‘optimize’ by charging more, doing less, and insisting that I am getting my money’s worth despite any contradictory evidence. How many technology vendors offer this sort of value? I think both Apple and Amazon are good examples on different ends of the cost spectrum, but what percentage of security companies hit that mark? To be honest, it’s something I worry about for Securosis all the time – value is something I believe in, and when you’re inside the machine it’s often hard to know if you are providing what you think. With another kid on the way the odds are low we’ll be getting back to Disney, or Buffett, any time soon. I suppose that’s good for the budget, but to be honest I look forward to the day the little one is big enough to be scared by a six foot rat in person. On to the Summary: Once again our writing volume is a little low due to extensive travel and end-of-year projects… Webcasts, Podcasts, Outside Writing, and Conferences Mr. Mortman on cloud security at VentureBeat. Adrian gets a nod on big data security. Favorite Securosis Posts Adrian Lane & David Mortman: Incite 11/7/2012: And the winner is… Math. Mike Rothman: Defending Against DoS Attacks [New Paper] and Index of Posts. Yes it’s a paper I wrote and that makes me a homer. But given the increasing prevalence of DoS attacks, it’s something you should get ahead of by reading the paper. Other Securosis Posts Implementing and Managing Patch and Configuration Management: Leveraging the Platform. Implementing and Managing Patch and Configuration Management: Configuration Management Operations. Implementing and Managing Patch and Configuration Management: Patch Management Operations. Implementing and Managing Patch and Configuration Management: Defining Policies. Building an Early Warning System: Internal Data Collection and Baselining. Building an Early Warning System: The Early Warning Process. Incite 11/14/2012: 24 Hours. Securing Big Data: Security Recommendations for Hadoop and NoSQL [New Paper]. Favorite Outside Posts (A few extras because we missed last week) Rich: Wher is Information Security’s Nate Silver? David Mortman: Maker of Airport Body Scanners Suspected of Falsifying Software Tests. Dave Lewis: Are you scared yet? Why cloud security keeps these 7 execs up at night. Mike Rothman: Superstorm Sandy Lessons: 100% Uptime Isn’t Always Worth It. Another key question is how much are you willing to pay to

Sometimes things don’t go your way. Maybe it’s a promotion you don’t get. Or a deal you don’t close. Or a part in the Nutcracker that goes to someone else. Whatever the situation, of course you’re disappointed. One of the Buddhist sayings I really appreciate is “suffering results from not getting what you want. Or from getting what you don’t want.” Substitute disappointment for suffering, and there you are. We have all been there. The real question is what you do next. You have a choice. You can be pissy for days. You can hold onto your disappointment and make everyone else around you miserable. These people just can’t recover when something bad happens. They go into a funk for days, sometimes weeks. They fall and can’t seem to get up. They suck all the energy from a room, like a black hole. Even if you were in a good mood, these folks will put you in a bad mood. We all know folks like that. Or you can let it go. I know, that’s a lot easier said than done. I try my best to process disappointment and move on within 24 hours. It’s something I picked up from the Falcons’ coach, Mike Smith. When they lose a game, they watch the tape, identify the issues to correct, and rue missed opportunity within 24 hours. Then they move on to the next opponent. I’m sure most teams think that way, and it makes sense. But there are some folks who don’t seem to feel anything at all. They are made of Telfon and just let things totally roll off, without any emotion or reaction. I understand the need to have a short memory and to not get too high or too low. The extremes are hard to deal with over long periods of time. But to just flatline at all times seems joyless. There must be some middle ground. I used to live at the extremes. I got cranky and grumpy and basically be that guy in a funk for an extended period. I snapped at the Boss and kids. I checked my BlackBerry before bed to learn the latest thing I screwed up, just to make sure I felt bad about myself as I nodded off. That’s when I decided that I really shouldn’t work for other people any more – especially not in marketing. Of course I have a short-term memory issue, and I violated that rule once more before finally exorcising those demons once and for all. But even in my idyllic situation at Securosis (well, most of the time) things don’t always go according to plan. But often they do – sometimes even better than planned. The good news is that I have gotten much better about rolling with it. I want to feel something, but not too much. I want to enjoy the little victories and move on from the periodic defeats. By allowing myself a fixed amount of time (24 hours) to process, I ensure I don’t go into the rat hole or take myself too seriously. And then I move on to the next thing. I can only speak for myself, but being able to persevere through the lows, then getting back up and moving forward, allows me to appreciate all the great stuff in my life. And there is plenty of it. –Mike Photo credits: 24 Hours Clock originally uploaded by httsan Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can get all our content in its unabridged glory. And you can get all our research papers too. Building an Early Warning System Internal Data Collection and Baselining The Early Warning Process Introduction Implementing and Managing Patch and Configuration Management Configuration Management Operations Patch Management Operations New Papers Defending Against Denial of Service Attacks Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments Pragmatic WAF Management: Giving Web Apps a Fighting Chance Incite 4 U Who sues the watchmen? Whenever you read about lawsuits, you need to take them with a grain of salt – especially here in the US. The courts are often used more as a negotiating tool to address wrongs, and frivolity should never be a surprise in a nation (world, actually) that actually thinks a relationship between two extremely wealthy children is newsworthy. That said, this lawsuit against Trustwave and others in South Carolina is one to watch closely. From the article it’s hard to tell whether the suit attacks the relationship between the company and lawmakers, or is more focused on negligence. Negligence in an area like security is very hard to prove, but anything can happen when the call goes to the jury. I can’t think of a case where a managed security provider was held liable for a breach, and both the nature and outcome of this case could have implications down the road. (As much as I like to pick on folks, I have no idea what occurred in this breach, and this could just be trolling for dollars or political gain). – RM What does sharing have to do with it? Congrats to our buddy Wade Baker, who was named one of Information Security’s 2012 Security 7 winners. Each winner gets to write a little ditty about something important to them, and Wade puts forth a well-reasoned pitch for more math and sharing in the practice of information security. Those aren’t foreign topics for folks familiar with our work, and we think Wade and his team at Verizon Business have done great work with the VERIS framework and the annual DBIR report. He sums up the challenges pretty effectively: “The problem with data sharing, however, is that it does not happen automatically. You hear a lot more people talking about it than actually doing it. Thus, while we may have the right prescription, it doesn’t

The key high-level difference between configuration and patch management is that configuration management offers more opportunity for automation than patch management. Unless you are changing standard builds and/or reevaluating benchmarks – then operations are more of a high-profile monitoring function. You will be alerted to a configuration change, and like any other potential incident you need to investigate and determine the proper remediation as part of a structured response process. Continuous Monitoring The first operational decision comes down to frequency of assessment. In a perfect world you would like to continuously assess your devices, to shorten the window between attack-related configuration change and detection of the change. Of course there is a point of diminishing returns, in terms of device resources and network bandwidth devoted to continuous assessment. Don’t forget to take other resource constraints into account, either. Real-time assessment doesn’t help if it takes an analyst a couple days to validate each alert and kick off the investigation process. Another point to consider is the increasing overlap between real-time configuration assessment and the host intrusion prevention system (HIPS) capabilities built into endpoint protection suites. The HIPS is typically configured to catch configuration changes and usually brings along a more response-oriented process. That’s why we put configuration management in a periodic controls bucket in the Endpoint Security Management Buyer’s Guide. That said there is a clear role for configuration management technology in dealing with attacks and threats. It’s a question of which technology – active HIPS, passive configuration management, or both – will work best in your environment. Managing Alerts Given that many alerts from your configuration management system may indicate attacks, a key component of your operational process is handling these alerts and investigating each potential incident. We have done a lot of work on documenting incident response fundamentals and more sophisticated network forensics, so check that research out for more detail. For this series, a typical alert management process looks like: Route alert: The interface of your endpoint security management platform acts as the initial view into the potential issue. Part of the policy definition and implementation process is to set alerts based on conditions that you would want to investigate. Once the alert fires someone then needs to process it. Depending on the size of your organization that might be a help desk technician, someone on the endpoint operations team, or a security team member. Initial investigation: The main responsibility of the tier 1 responder is to validate the issue. Was it a false positive, perhaps because the change was authorized? If not, was it an innocent mistake that can be remedied with a quick fix or workaround? If not, and this is a real attack, then some kind of escalation is in order, based on your established incident handling process. Escalation: At this point the next person in the chain will want as much information as possible about the situation. The configuration management system should be able to provide information on the device, the change(s) made, the user’s history, and anything else that relates to the device. The more detail you can provide, the easier it will be to reconstruct what actually happened. If the responder works for the security team, he or she can also dig into other data sources if needed, such as SIEM and firewall logs. At this point a broader initiative with specialized tools kicks in, and it is more than just a configuration management issue. Close: Once the item is closed, you will likely want to generate a number of reports documenting what happened and the eventual resolution – at least to satisfy compliance requirements. But that shouldn’t be the end of your closing step. We recommend a more detailed post-mortem meeting to thoroughly understand what happened, what needs to change to avoid similar situations in the future, and to see how processes stood up under fire. Also critically assess the situation in terms of configuration management policies and make any necessary policy changes, as we will discuss later in this post. Troubleshooting In terms of troubleshooting, as with patch management, the biggest risk for configuration change is that might not be made correctly. The troubleshooting process is similar to the one laid out in Patch Management Operations, so we won’t go through the whole thing. The key is that you need to identify what failed, which typically involves either a server or agent failure. Don’t forget about connectivity issues, which can impact your ability to make configuration changes as well. Once the issue is addressed and the proper configuration changes made, you will want to confirm them. Keep in mind the need for aggressive discovery of new devices, as the longer a misconfigured device exists on your network, the more likely it is to be exploited. As we discussed in the Endpoint Security Management Buyer’s Guide, whether it’s via periodic active scanning, passive scanning, integration with the CMDB (or another asset repository) or another method, you can’t manage what you don’t know exists. So keep focus on a timely and accurate ongoing discovery process. Optimizing the Environment When you aren’t dealing with an alert or a failure, you will periodically revisit policies and system operations with an eye to optimizing them. That requires some introspection, to critically assess what’s working and what isn’t. How long is it taking to identify configuration changes, and how is resolution time trending? If things move in the wrong direction try to isolate the circumstances of the failure. Are the problems related to one of these? Devices or software Network connectivity or lack thereof Business units or specific employees When reviewing policies trends are your friend. When the system is working fine you can focus on trying to improve operations. Can you move, add, or change components to cut the time required for discovery and assessment? Look for incremental improvements and be sure to plan changes carefully. If you change too much at one time it will be difficult to figure out what worked and

Now that we have provided the reasons you need to start thinking about an Early Warning System, and a high-level idea of the process involved, it’s time to dig into the different parts of the process. Third-party intelligence, which we’ll discuss in the next post, will tell you what kinds of attacks you are more likely to see, based on what else is happening in the world. But monitoring your own environment and looking for variation from normal activity tell you whether those attacks actually ARE hitting you. Internal Data Collection The process starts with collecting data from your internal sources for analysis. Most of you already have data aggregated in a log management environment because compliance has been mandating log management for years. More advanced organizations may have a Security Operations Center (SOC) leveraging a SIEM platform to do more security-oriented correlation and forensics to pinpoint and investigate attacks. Either way, you are likely collecting data which will provide the basis for the internal side of your EWS. Let’s take a quick look at the kinds of data you are likely already collecting and their relevance to the EWS: Network Security Devices: Your firewalls and IPS devices generate huge logs of what’s blocked, what’s not, and which rules are effective. The EWS will be matching attack patterns and traffic to what is known about other attacks, so recognizing port/protocol/destination combinations, or application identifiers for next-generation firewalls, will be helpful. Identity: Similarly, information about logins, authentication failures, and other identity-related data is useful for matching against attack profiles received from the third-party threat intelligence providers. Application/Database Logs: Application specific logs are generally less relevant, unless they come from standard applications or components likely to be specifically targeted by attackers. Database transaction logs are generally more useful for identifying unusual database transactions – which might represent bulk data removal, injection attempts, or efforts to bring applications down. Database Activity Monitoring (DAM) logs are useful for determinining the patterns of database requests, particularly when monitoring traffic within the database (or on the database server) consumes too many resources. NetFlow: Another data type commonly used in SIEM environments is NetFlow – which provides information on protocols, sources, and destinations for network traffic as it traversing devices. NetFlow records are similar to firewall logs but far smaller, making them more useful for high-speed networks. Network flows can identify lateral movement by attackers, as well as large file transfers. Vulnerability Scans: Scans offer an idea of which devices are vulnerable to specific attacks, which is critical for the EWS to help pinpoint which devices would be potential targets for which attacks. You don’t need to to worry about Windows exploits against Linux servers so this information enables you to focus monitoring, investigations, and workarounds on the devices more likely to be successfully attacked. Configuration Data: The last major security data category is configuration data, which provides information on changes to monitored devices. This is also critical for an EWS, because one of the most important intelligence types identifies specific malware attacks by their signature compromise indications. Matching these indicators against your configuration database enables you to detect successful (and even better, in-progress) attacks on devices in your environment. After figuring out which data you will collect, you need to decide where to put it. That means selecting a platform for your Early Warning System. You already have a SIEM/Log Management offering, so that’s one possibility. You also likely have a vulnerability management platform, so that’s another choice. We are not religious about which technology gets the nod, but a few capabilities are essential for an EWS. Let’s not put the cart before the horse, though – we don’t yet have enough context on other aspects of the process to understand which platform(s) might make sense. So we will defer the platform decision until later in this series. Baseline Once the data is collected, before it is useful to the EWS you need to define normal. As we mentioned earlier, ‘normal’ does not necessarily mean secure. If you are anything like almost every other enterprise, you likely have malware and compromised devices on your network already. Sorry to burst your bubble. You need to identify indications of something different. Something that could represent an attack, an outbreak, or an exfiltration attempt. It might be another false positive, or it could represent a new normal to accept, but either way the baseline will need to adapt and evolve. Let’s highlight a simple process for building a baseline: Pick data source(s): Start by picking a single data source and collect some data. Then determine the ranges you see within the data set. As an example we will use firewall logs. You typically have the type of traffic (ports, protocols, applications, etc.), the destination IP address, the time of day, and whether the packet was blocked, from the log. You can pick numerous data sources and do sophisticated data mining, but we will keep it simple for illustration purposes. Monitor the patterns: Then collect traffic for a while, typically a few days to a week, and then start analyzing it. Get your inner statistician on and start calculating averages, means, medians, and frequencies for your data set. In our example you might determine that 15% of your inbound web traffic during lunchtime is SSL destined for your shipping cart application. Define the initial thresholds: From the initial patterns you can set thresholds, outside which traffic indicate a potential problem. Maybe you set the initial thresholds 2 standard deviations above the mean for a traffic type. You look at the medians and means to figure out which initial threshold makes sense. You don’t need to be precise with the initial threshold – you don’t yet have enough data or knowledge to know what represents an attack – but to give you a place to start. Getting back to our firewall example, a spike in outbound SSL traffic spike to 30% might indicate an exfiltration. Or it could indicate a bunch

Now that we have gone through all the preparation, deployed the technology, and set up policies, we need to operate our patch management environment. That will be our focus in this post. As we discussed in the Policy Definition post, there isn’t a huge amount of monthly leverage to be gained for patch management. You need to do the work of monitoring for new patches, assessing each new patch for deployment, testing the patches prior to deployment, bundling installation packages, and then installing the patches on affected devices. You will be performing each of those activities each month whether you like them or not. We have already delved into those monthy activities within the context of defining policies, so let’s take things a step deeper. Troubleshooting The biggest issue with Patch Management Operations is that a patch may not install properly, for whatever reason. So the first operational task is to ensure the integrity of the process – that the patch was installed and operates properly. As we described in Patch Management Quant in great detail, once the patch is confirmed the tool also needs to clean up any patch residue (temp files, etc.). In the event the patch doesn’t deploy properly, you go to a clean up step – which involves identifying the failed deployment, determining the reason for the failure, adjusting the deployment parameters, and eventually reinstalling. For instance, here are three typical patch failure reasons which can be isolated fairly easily: Relay fail: If you have deployed a hierarchical environment to better utilize bandwidth, your relay points (distribution servers) may not be operating properly. It could be a server failure or a network issue. If an entire site or location doesn’t successfully patch, that’s a strong indication of a distribution problem. It’s not brain surgery to diagnose many of these issues. Agent fail: Another likely culprit is failure of an endpoint agent to do what it’s supposed to. If installation failures appear more random this might be the culprit. You will need to analyze the devices to make sure there are no conflicts and that the user didn’t turn off or uninstall the agent. Policy fail: As unlikely as it is, you (or your ops folks) might have configured the policies incorrectly. This is reasonably common – you need to set up policies each patch cycle, and nobody is perfect. There are many other reasons a patch might not deploy properly. The point is to address one-off situations as necessary, but also to make sure there isn’t a systemic problem with your process. You will use this kind of troubleshooting analysis and data to move on to the next step of operating your patch environment: to optimize things. Optimizing the Environment Just like any other optimization process, this one starts with a critical review of the current operation. What works? What doesn’t? How long does it take you to patch 75% of your managed devices? 90%? 100%? Is that increasing over time, or decreasing? What types of patches are failing (operating systems, apps, servers, endpoints, or something else)? How does device location (remote vs. on-network) affect success rates? Are certain business units more successful than others? During the review, consider adding new policies and groups. Though be careful since patch management requires a largely manual effort each month, there is a point of diminishing returns to defining very rigid policies to achieve better automation. If you find the environment reasonably stable, periodic reviews become more about tuning polices than overhauling them. This involves revisiting your deployment and figuring out whether you have the right hierarchy to effectively distribute patches. Do you need more distribution points? Less? Are you optimizing bandwidth? Do you need to install agents to achieve more granular management? Or perhaps remove agents, if you can patch without persistent agents on the devices. You look for incremental improvement here, so changes should be highly planned-out and structured. This enables you to isolate the effect of each change and reevaluate each aspect iteratively. If you change too much at one time it will be difficult to figure out what worked and what didn’t. Also pay attention to maintenance of your environment. The servers and distribution points need to be backed up and kept current, along with updating the agents as needed. Obviously you need to test infrastructure software updates – just like any other patch or update – prior to deployment, but the patching system itself could be an attacker’s target, so you need to keep it up to date as well. We tend to be wary of automatic updating for most enterprise security tools – there are too many example of bad updates wreaking havoc for it to feel comfortable. Improvements in quicker implementation can easily be lost if you take down your environment while you try to back out a busted patch. Documentation Finally, you defined a bunch of reports earlier in the process, to run on an ongoing basis. Obviously you need these artifacts for compliance purposes, but pay attention to the operational data they generate yourself. Feed that information back into the process to continually improve your patch management. Share:

We are pleased to put the finishing touches on our Denial of Service (DoS) research and distribute the paper. Unless you have had your head in the sand for the last year, you know DoS attacks are back with a vengeance, knocking down sites both big and small. It is no longer viable to ignore the threat, so we all need to think about what to do when we inevitably become a target. This excerpt from the paper’s introduction should give you a feel for what we’re talking about. For years security folks have grumbled about the role compliance has assumed in driving investment and resource allocation in security. It has become all about mandates and regulatory oversight driving a focus on protection, ostensibly to prevent data breaches. We have spent years in the proverbial wilderness, focused entirely on the “C” (Confidentiality) and “I” (Integrity) aspects of the CIA triad, largely neglecting “A” (Availability). Given how many breaches we still see every week, this approach hasn’t worked out too well. Regulators pretty much only care whether data leaks out. They don’t care about the availability of systems – data can’t leak if the system is down, right? Without a clear compliance-driven mandate to address availability (due to security exposure), many customers haven’t done and won’t do anything to address availability. Of course attackers know this, so they have adapted their tactics to fill the vacuum created by compliance spending. They increasingly leverage availability-impacting attacks to both cause downtime (costing site owners money) and mask other kinds of attacks. These availability-impacting attacks are better known as Denial of Service (DoS) attacks. We focus on forward-looking research at Securosis. So we have started poking around, talking to practitioners about their DoS defense plans, and we have discovered a clear knowledge gap around the Denial of Service attacks in use today and the defenses needed to maintain availability. There is an all too common belief that the defenses that protect against run of the mill network and application attacks will stand up to a DoS. That’s just not the case, so this paper will provide detail on the attacks in use today, suggest realistic defensive architectures and tactics, and explain the basic process required to have a chance of defending your organization against a DoS attack. Direct Download (PDF): Defending Against Denial of Service (DoS) Attacks We would like to thank (in alphabetical order) Arbor Networks, Corero Network Security, F5 Networks, and Radware for licensing the content in this paper. Obviously we wouldn’t be able to do the research we do, or offer it to you folks for this most excellent price, without clients licensing our content. If you want to go back through the archives to see the blog series that formed the basis for this paper, here you go: Introduction The Attacks Defense, Part 1: the Network Defense, Part 2: Applications The DoS Defense Process Share: