Research

Getting ahead of the attackers is the holy grail to security folks. A few years back some vendors sold their customers a bill of goods, claiming they could “get ahead of the threat.” That didn’t work out so well, and most of the world appreciates that security is a reactive situation. The realistic objective is to reduce the time it takes to react. We call this React Faster and Better. The foundation of the philosophy is an effective incident response process. But you can shrink the window of exploitation by leveraging cutting-edge research to help focus your efforts more effectively. You need an early warning system for perspective on what’s coming at you. Pragmatic Intelligence Back in 2007 when the Pragmatic CSO was written, prioritization was a key part of the operational methodology espoused as part of the P-CSO process. Over the past 5 years we have kept focus on the importance of prioritizing your limited funding, resources, and expertise, on the highest-value activities. To get a feel for how this concept works, let’s excerpt a small section from the Pragmatic CSO: [A key operational discipline is] figuring out the most likely exposure and working to eliminate it. This is particularly hard because many CSOs run from emergency to emergency without ever getting a chance to manage their security environment or even spend 10 minutes thinking about what is next. Unfortunately, what’s next has already happened. Clearly this situation must be addressed. “A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be.” – Wayne Gretzky The great ones, in whatever pursuit, figure out how to anticipate what is most likely to happen, so they are ready if it does. Some think it’s luck, others figure it’s a talent bestowed by a higher power. Actually, in most cases, it is the result of a tremendous amount of hard work. The ability to anticipate is especially critical in security because of the unlimited number of possible attacks across an infinite attack surface. You cannot cover all the bases, so you need to be focused and choose correctly. What is the best way to choose correctly? You need an “inside man” working on your behalf to figure out what the bad guys are working on. Thus, security research plays a critical role in the life of a Pragmatic CSO. It’s hard to believe, but Pragmatic CSOs read a lot. They are plugged into the underground networks of researchers that spend time penetrating the hacker networks and tracking down the bot masters to figure out what they are working on. If you know what the bad guys are focused on, you can get a real good idea about what they are planning to strike next. Even though you don’t have to spend money to get connected with the research folks, a number of services focus on reporting new exploits and figuring out what is most likely to be attacked on any given day. Of course context is everything, so although third party research may give you a clue to what the next exploit or botnet looks like, it cannot tell you how it will be used against your defenses. You need to provide that context, which requires looking at the situation from two different perspectives: In Here: This is the internal perspective gleaned from what’s happening on your network. Whether the platform to aggregate and analyze the data is a SIEM or a Vulnerability Management platform or any other technology, the point is the same. The foundation for context is a clear understanding of what’s going on within your environment. Then you can move on to the next view for an idea of what’s exposed and what needs to be fixed right now. Out There: The reverse perspective looks at the macro environment, understanding attacker tactics and exploits, and then figuring out how they will affect you. If you know about attacks you can preemptively implement protections. Obviously you need to walk before you run, so getting a handle on your internal security data is a necessary first step. But once you are there, factoring in the external view can really help narrow down your attack surface. None of this is new. Law enforcement has been doing this, well, forever. The goal is to penetrate the adversary, learn their methods, and take action before an attack. Even in security there is a lot of precedent for this kind of approach. Back at TruSecure over a decade ago, the security program was based on performing external threat research, and using it to prioritize the controls to be implemented to address imminent attacks. Amazingly enough it worked. But this approach fell out of favor over the past 5-7 years as the entire industry got weighed down by the compliance albatross. Now that the pendulum is swinging back toward actually securing stuff, we see a resurgence of threat intelligence as a way to make our defenses more effective and efficient. Let’s run through the history of security research, now typically called threat intelligence. The Evolution of Threat Intelligence Back in the day, security research really meant anti-virus research. The AV companies would look at viruses, build signatures, and move on to the next one. It was a fairly collegial environment, and AV companies shared the malware they discovered, making sure everyone was protected within a couple hours. The next wave of research resulted from the avalanche of spam, which required security companies to build global networks of honeypots to capture bad email directly, create signatures to identify it, and distribute the signatures to their gateways. Of course, that lasted only until the spammers became more effective at evading signatures, which drove heavier reliance on behavioral indicators to infer which files were malware and which messages were spam. This required security vendors to spend time evaluating behavior and tuning their detection cocktails to maintain efficiency. At about this time, IP and file reputation started to be more

By this point planning should be complete. You have designed your patch and configuration management processes, defined priorities to manage the devices in your environment, figured out which high-level implementation process to start with, discovered the devices in your environment, and performed initial testing to make sure the new technology doesn’t break anything. Now it’s time to integrate the patch and configuration management tools into your environment. Enough of this planning stuff, let’s get down to business! But you won’t actually remediate anything yet – the initial focus is on integrating technical components, installing agents as necessary, and preparing to flip the switch. Component Overview We are grouping patch and configuration management together, so we will talk about generic concepts like management servers and agents. A management server might be specifically associated with a patch management product and/or the configuration management environment. Obviously you want leverage between the two, but depending on which technologies you selected you might have different consoles and agents. But the deployment considerations are similar, regardless of the specific use case. Before we describe specific components we need to briefly go over the inherent security requirements of the different components. If an attacker can change the configuration of a device or apply a malicious patch, it’s pretty much game over. So it’s important to make sure the components are deployed correctly with appropriate security controls. Most solutions use some type of cryptography, both for authentication and to protect communications between components. We are not religious about specific authentication mechanisms (PKI or Windows or whatever), but be sure to check for recent attacks or vulnerabilities for whichever technologies you depend on. You may also want to consider two-factor authentication or some kind of privileged user management technology to better protect the management console. You will also need to coordinate with the network team to make sure the proper firewall ports are open (and/or proxies identified) to receive updates/new patches from vendors, and to communicate with the relays and/or endpoints using the ports specified by your endpoint security management vendor. Be considerate of the network security team, of course, who will likely resist opening up all sorts of ports throughout the environment. Default deny is still your friend – so when planning the deployment make sure you understand where the servers, distribution points & relays, and agents will be implemented, and how they communicate. Management Server/Appliance The management server is the brains of the operation. It holds the policies and provides the focal point for data aggregation, analysis, visualization, and reporting. You have a few options for how to implement the management server, so let’s discuss the pros and cons of each. Software: The most common choice is to install software on a dedicated server. Depending on your product this might actually run across multiple physical servers for different internal components such as a back-end database, or to distribute functions for better performance. Some products require different software components running concurrently to manage different functions. This is frequently a legacy of mergers and acquisitions – most products converge on a single software base, although integration may not be as complete as you would expect. Management server overhead is generally fairly low, especially outside large enterprises, so this server often handles some network monitoring, functions as the email MTA (for alerting), and manages endpoint agents. A small-to-medium-sized organization generally only needs to deploy additional servers for load balancing or hot standby. Integration is easy – install the software and position the physical server wherever needed, based on deployment priorities and network configuration, ensuring visibility to the relays and/or agents that need to communicate with it. Appliance: In this scenario the endpoint security management software comes preinstalled on dedicated hardware, presumably with a locked-down secure operating system. There is no software to install, so the initial integration is usually a matter of connecting it to the network and setting a few basic options – we will cover the full configuration later. As with a standard server, the appliance usually includes the ability to run multiple functions (though you might need licenses to unlock capabilities). Virtual Appliance: The endpoint security management software is preinstalled into a virtual machine for deployment as a virtual server. This is similar to an appliance but requires work to get up and running on your virtualization platform of choice, configure the network, and then set up the initial configuration options as if it were a physical server or appliance. For now just get the tool up and running so you can integrate the other components. Do not deploy any policies or turn on monitoring yet. Agents (or Not) Endpoint agents are, by far, the most varied patch and configuration management components. There are huge differences between the various products on the market, with far more severe performance constraints running on general-purpose workstations and laptops than on dedicated servers. Fortunately, as widely as features and functions vary, the deployment process is consistent. Test, then test more: We know we keep telling you to test your endpoint agents, but that’s not an accident – inadequate testing is the single most common problem people encounter. If you haven’t already, make sure you test your agents on a variety of real-world systems in your environment to make sure performance and compatibility are acceptable. That’s why choosing test devices in the preparation step is so important. Create a deployment package or enable in your EPP tool: The best way to deploy any agent is to use whatever software distribution tool you already use for normal system updates. There is no need to reinvent the wheel here. This means building a deployment package with the agent configured to connect to the patch and/or configuration management server. Remember to account for any network restrictions that could isolate endpoints from the server. In some cases the agent may be integrated into your existing EPP (Endpoint Protection Platform) tool. More often you will need to deploy an additional agent, but if it is fully integrated

As we described in the Introduction to Implementing and Managing Patch and Configuration Management, endpoint hygiene is key to endpoint security management. WIth the product (or service) in hand, it’s time to get the technology implemented and providing value as quickly as possible. You know the old saying, “if you fail to prepare, you prepare to fail.” It’s actually true, and the preparation in this situation involves ensuring your processes are solid, defining device coverage and roll-out priorities, figuring out what’s already out there, and finally going through a testing phase to make sure you are ready to deploy widely. So, let’s revisit the patch and configuration management processes. Determine Processes We are process centric at Securosis. We admit it, but only because we understand the folly of trying to implement and manage technology without proper processes and accountabilities defined before products get installed. So we start most activities with a check to ensure the process supports the problem to be solved. With patch and configuration management, you are looking at two distinct but tightly intertwined processes. To be clear, you don’t have to do all the functions described below. Figure out which will work for your organization. But you do need to make sure everyone understands what they are supposed to do – especially when it comes to remediation. If the operations team is expected to run through the patch process, open up the maintenance windows, and confirm the successful implementation of each patch, they need to know that. Likewise, if the incident response team needs to investigate strange configuration changes found during assessment, the handoffs must be clearly defined, as well as your ability to remediate a device under investigation. Patch Management Discover and define targets: Before you jump into the Patch Management process you need to define which devices will be included. Is it just endpoints, or do you also need to patch servers? These days you also need to think about cloud instances. The technology is largely the same, but increased numbers of devices make execution more challenging. Obtain patches: You need to monitor for release of relevant patches, and then figure out whether you need each patch, or you can work around the issue. Prepare to patch: Once the patch is obtained you need to figure out how critical the issue is. Is it something you need to fix right now? Can it wait for the next maintenance window? Once priority is established give the patch a final Q/A check to ensure it won’t break anything important. Deploy the patch: Once preparation is complete and your window has arrived, you can install. Confirm the patch: Patches don’t help if the install fails, so confirm that each patch is fully installed. Reporting: Compliance requirements for timely patching make reporting an integral function. Obviously this is a very high-level process description. If you want a much more granular process map for patch management, with metrics and cost models, check out Patch Management Quant. Configuration Management Establish configuration baselines and/or benchmarks: First define acceptable secure configurations for each managed device type. Many organizations start with benchmarks from CIS or NIST (PDF) for granular guidance on how devices should be configured. Discover and define targets: Next find the devices that need to be managed. Ideally you can leverage an endpoint security management platform with an integrated asset management repository. You will also want to categorize and group assets to avoid unnecessary services. Engineering workstations, for example, require different configurations than Finance systems. Assess, alert, and report changes: Once devices are discovered and categorized, define a frequency for assessments. How often will you check them against policy? Some vendors use the term “continuous assessment”, but their assessments aren’t really continuous. Fortunately this isn’t normally a problem – not least because most operational groups wouldn’t be able to validate alerts and correct issues in real time anyway. Remediate: Once a problem is identified, either it needs to be fixed or someone needs to grant an exception. You are likely to have too much work to handle it all immediately so prioritization is key. We offered some perspective on prioritization for vulnerability management, but the concepts are the same for configuration management. You will also probably need to verify that changes actually took place for the audit, as well as plan for a roll-back in case the change breaks something. Define Initial Priorities/Targets and Deployment Model After gaining consensus on the applicable processes and ensuring everyone knows their roles and responsibilities, it’s time to determine your initial priorities/targets to figure out whether you will start with the Quick Wins process or jump right into Full Deployment. Most organizations have at least a vague sense of what types of devices they need to patch and manage, but translating that into deployment priorities can be tricky. Let’s highlight some of the categories of things you can manage, which should help you figure out the best direction. Servers: (OS) Keeping server devices updated is essential for protecting them. Look to group servers logically based on function, so you can identify typical configurations and applicable patch windows for each class of device. Also factor in whether you are dealing with physical servers, private cloud instances, or public cloud instances, because managing each type differs dramatically. PCs: (OS) Though non-server PCs are rarely the ultimate target of an attack, they provide a way for attackers to gain a foothold within your organization, so they can jump laterally to attack servers. Group PCs logically based on job function and need for access to critical data stores. Keep in mind that laptops create unique problems for to patch and configuration management because they may connect to the network infrequently, so consider whether you want to tackle that as part of the initial deployment. Mobile devices: (OS) Quicker than you can say BYOD, you will need to more effectively manage the mobile devices (including smartphones) that access your network. The smartphone vendors provide utilities to update and enforce configuration policies

We are relaunching one of our more popular white papers, Tokenization vs. Encryption: Options for Compliance. The paper was originally written to close some gaps in our existing tokenization research coverage and address common user questions. Specifically, how does tokenization differ from encryption, and how can I decide which to use? We believe tokenization is particularly important, for several reasons. First, in an evolving regulatory landscape, we need a critical examination of tokenization’s suitability for compliance. There are many possible applications of tokenization, and it’s simpler and easier to use than many other security tools. Second, we wanted to dispel the myth that tokenization is a replacement technology for encryption, when in fact it’s a complimentary solution that – in some cases – makes regulatory compliance easier. Finally, not all of the claimed use cases for tokenization are practical at this time. These questions keep popping up, so we feel a relaunch is in order. This paper discusses the use of tokenization for payment data, personal information, and health records. The paper was written to address questions regarding the business applicability of tokenization, and therefore far less technical than most of our research papers. The content has been updated slightly to reflect some of the changes in the PCI Council’s stance on PCI and address some questions which arise when considering tokenization for PHI and PII. I hope you enjoy reading it as much as I enjoyed writing it. A special thanks to Intel and Prime Factors for sponsoring this research! Download: Tokenization vs. Encryption: Options for Compliance, version 2. Share:

Some days I miss when the kids were little. It’s not that I don’t appreciate being able to talk in full sentences, pick apart their arguments and have them understand what I’m talking about, or apply a heavy bit of sarcasm when I respond to some silly request. I don’t think I’d go back to the days of changing diapers, but there was a simplicity to child rearing back then. We don’t really appreciate how quickly time flies – at least I don’t. I blinked and the toddlers are little people. We were too busy making sure all the trains ran on time to appreciate those days. The other day the Boss and I were franticly trying to get dinner ready. Being the helpful guy I am (at times), I asked what was for dinner, so I could get the proper bowls and utensils. I think it was hot dogs, corn, and fruit salad. Once she said, “fruit salad,” I instinctively blurted out “Yummy Yummy.” She started cracking up. Those of you not going through the toddler phase over the past 7 years probably have no idea what I’m talking about. Those who have know I am talking about the Wiggles. I remember back to the days of watching those 4 Australians dance around to silly, catchy songs – and maybe even teach the kids a thing or two. But far more important at that time, the Wiggles kept the kids occupied for 30 minutes and allowed us frantic parents to get a little of our sanity back. So in a strange way, I miss the Wiggles. I don’t miss the time we drove up to Maryland for the holidays and the kids watched all of the Wiggles DVDs we had in a row. After 10 hours of that, if I saw any Wiggles I certainly wouldn’t have been wielding a Feathersword. And now that I think about it, most of the songs were pretty annoying. So I guess I don’t miss the Wiggles after all. But I do miss that stage when the kids were easier. When it was about learning the ABCs, not putting competitive grades on the board to get into a good college. When we could focus on learning T-ball skills, not what sport to specialize in to have any hope of playing in high school. When the biggest issue was the kids not sharing the blocks nicely, rather than the $tween hormonal mayhem we need to manage now. As I look back, the songs may not actually have been yummy, yummy, but those times were. –Mike Photo credits: Ben-Anthony-throw-fruit originally uploaded by OneTigerFan 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. Implementing and Managing Patch and Configuration Management Introduction Understanding and Selecting a Key Manager Introduction Defending Against Denial of Service (DoS) Attacks The Process Defense, Part 2: The Applications Understanding and Selecting Identity Management for Cloud Services Introduction Incite 4 U It’s about finding the unknown unknowns: I seem to constantly be talking to enterprises about SIEM, and they seem surprised when I state the obvious. Deploying this technology involves knowing what question you’re trying to answer, right? The idea of finding a targeted attack via correlation rules is pretty much hogwash. Wendy makes a good point in her recent Dark Reading post. She’s exactly right that having a lot of data doesn’t mean you know what to do with it. Data aggregation and simple correlation is only the first wave of the story. Harnessing new data analysis techniques, for those willing to make the investment, enables interesting technologies to identify patterns and indicate activity you don’t know about. Of course you still need some HUMINT (human intelligence) to figure out whether the patterns mean anything to your organization – like that you are under attack – but the current state of the art is finding what you already know, so this makes a nice improvement in the impact of analytics on security operations. – MR Ignorance is bliss: A recent study suggests that small organizations are confident in their security without any real plans. These results are really not surprising, and closely match my own research. Just about every small firm I speak with has no idea about what protections they should have in place. They also have no clue about possible threats. Sure, some are vaguely aware of what could happen, but they generally choose not to take the time or spend the money on security controls that could be ‘better’ spent elsewhere. But I worry more about the dozen or so small merchants I have spoken with, who must comply with PCI-DSS, but don’t understand any of the items described in their self-assessment questionnaires. It might as well be written in a foreign language. And of course they don’t have security policies or procedures to achieve compliance – they have passwords and a firewall, all managed by the same guy! Failure just waiting to happen. – AL 2008 called, and it wants its whitelist back: I read this announcement of new Forrester research calling for increased use of application whitelisting. Wait, what? I thought that battle was over – and we had all agreed that AWL is a good alternative for fixed function devices like kiosks, ATMs, factory floor equipment, and call center devices – but for knowledge workers not so much. At least that’s what Mr. Market says. To be fair, I agree with the concept. If malware can’t execute that’s a good thing. But the collateral user experience damage makes this a non-starter for many enterprises. Especially when there are other alternatives refining the behavioral approaches of the past. – MR Elephant in a box: While it’s not a security related issue, Teradata’s (TD) announcement

Endpoint devices have been the bane of security practitioners for as long as we can remember. Whether it’s unknowing users who click anything, folks who don’t think the rules apply to them, or the forgetful sorts who just leave their devices anywhere and everywhere, keeping control over endpoints causes heartburn at many organizations. To address these concerns, Securosis recently published our Endpoint Security Management Buyer’s Guide, which began with a list of the key issues complicating endpoint security management, including: Emerging Attack Vectors: Everyone wants to talk about advanced attacks because they are exciting and sexy, but many successful attacks stem from simple operational failures. Whether it’s an inability to patch in a timely fashion, or to maintain secure configurations, far too many people leave the proverbial barn doors open on their devices. Or attackers target users via sleight-of-hand and social engineering. Employees unknowingly open the doors for attackers – and enable data compromise. That doesn’t mean you don’t have to worry about advanced malware or persistent attackers, but if your operational house isn’t in order yet it would be premature. Device Sprawl: A typical organization has a variety of PC variants running numerous operating systems. Those PCs may be virtualized and may connect in from anywhere in the world – including networks you do not control. Even better, many employees carry smartphones in their pockets and tablets in their backpacks, but those devices are all just more computers. Any endpoint security management controls and processes you implement need to be consistently enforced across the sprawl of all your devices. BYOD: Mobile devices are the tip of the iceberg – many organizations are increasingly supporting BYOD (bring your own device) policies, which means you need to protect not only corporate computer assets but employees’ personal devices as well. So you need to support any variety of PC, Mac, smartphone, or tablet any employee wants to use. This requires the ability to granularly manage device policies. Additionally, patching an app on an employee device might break a device capability which the user/owner relies on. To provide this more strategic view of endpoint security management, we identified 4 specific controls typically used to manage the security of endpoints, and broke them up into periodic and ongoing controls, depicted below. To refresh your memory, here is a quick description of both patch and configuration management: Patch Management: Patch managers install fixes from software vendors to address vulnerabilities. The best known patching process comes from Microsoft on a monthly schedule. On Patch Tuesday, Microsoft issues a variety of software fixes to address defects that could result in exploitation of their systems. Once a patch is issued your organization needs to assess it, figure out which devices need to be patched, and ultimately install the patch within the window specified by policy – typically a few days. A patch management product scans devices, installs patches, and reports on the success and failure of the process. Configuration Management: Configuration management enables an organization to define an authorized set of configurations for devices in use within the environment. These configurations govern the applications installed, device settings, services running, and security controls in place. This is important because a changing configuration might indicate malware manipulation or an operational error. Additionally, configuration management can help ease the provisioning burden of setting up and reimaging devices. Configuration management enables your organization to define what should be running on each device based on entitlements, and to identify non-compliant devices. You bought the technology – what now? It’s time to implement and manage your new toys, so we are starting a new series entitled “Deploying and Managing Patch and Configuration Management” to document our research. As we mentioned in the Endpoint Security Management Buyer’s Guide, there is tremendous leverage between patch and configuration management offerings, so we will cover both controls in this series. Let’s dig a bit into the two deployment models to cover, and how we will work through the implementation and management processes. Quick Wins for long term success One of the main challenges in implementing any security technology is to show immediate value to justify the investment. Of course you can install patches and manage configurations manually, or using built-in and/or free utilities for the endpoints you manage. When spending money on patch and configuration management you need to focus on value – above and beyond what you already had – so we will break the implementation process into two phases, described below: The Quick Wins process is for initial deployments. Its focus is on rapid deployment on critical devices with access to sensitive data. You will take this opportunity to fine-tune the deployment and policies, which streamlines the path to full deployment later. The Full Deployment process is for the long haul. It’s a methodical series of steps to full enforcement of enterprise patch and/or configuration policies. The goal of both controls is to minimize exposure, which means ensuring patches are applied as quickly as practical, and monitoring configurations to ensure malware hasn’t made unauthorized configuration changes. The key difference is that the Quick Wins process doesn’t cover every endpoint – just the most important ones. It’s about getting up and running quickly, and helping set the stage for full deployment. Full Deployment is where you dig in, spend more time, and implement long-term policies across all devices. Full coverage is critical because today’s attackers often do not go directly after sensitive data stores. They tend to start slowly, gaining presence via known vulnerabilities and configuration mistakes, patiently moving laterally through the environment until they access their target. So we designed these processes to complement each other. If you start with Quick Wins, all your work feeds directly into Full Deployment. If you already know where you want to focus and have a mature endpoint management infrastructure, you can jump right into Full Deployment. Either way, our process guides you around common problems and should help speed implementation. Getting started No matter whether you choose Quick Wins

Hey everyone, I am pleased to finally announce the release of Pragmatic Key Management for Data Encryption. If you didn’t follow the posts that lead to this paper, the focus is on key management strategies for data encryption – rather than on certificate management, signing, or other crypto operations. I was able to narrow things down to four key strategies, and I also spend a little time talking about data encryption systems, as opposed to crypto operations (hashing, algorithms, etc.). You can visit the paper’s permanent home, and the direct download is: Pragmatic Key Management for Data Encryption (pdf) Share:

Research. It’s what I do. And long before I started work at Securosis I had a natural inclination toward it. Researching platforms, software toolkits, hardware, whatever. I want to know all the facts, and most of the rumors and anecdotes as well. I research things furiously. I’m obsessive about it. I will spend hour upon hour trying to answer every question I come up with, looking at all aspects of a product. This job lets me really indulge that facet of my personality – it makes the job enjoyable, and is the reason some research projects go a tad longer that I originally expected. And in an odd way it’s one of the reasons I really like the name Securosis – the name Rich chose for the company before I joined in. My research habits border a bit on neurosis, so it fits. This inclination bleeds over to my personal life as well. Detailed analysis, fact finding, understanding how things work, how the pieces fit, what options are available, using products when you can, or imaging how you might use them when you can’t. It’s a wonderful approach when you are making big purchases like a car or a home. The sheer volume of mental analysis spotlights bad decisions and removes emotion from the equation, and has saved me from several bad decisions in life. But it’s a bit absurd when you’re buying a pair of running shoes. Or a $20 crock pot. In fact it’s a problem. I have found that analysis takes a lot of the passion out of things. I can analyze a pair of headphones or an amplifier to death. Several items I have purchased over the years are really nice – possibly some of the finest of their types. Yet I am so aware of their faults that I have a tough time just enjoying these products. I can’t just plunk my money down and experience a new CD, a new bicycle, or a new office chair. Great when analyzing stocks – not so much at the Apple Store. Does a new pair of hiking boots really need 20 hours of fact finding? I don’t think so. The ability to just relax and enjoy rather than analyze and critique is a learned response – for me. Now that I have finally admitted my neurosis and accepted it, time to hit the ‘Buy’ button and enjoy my purchase, research be damned! One last item: Anyone else notice the jump in phishing attempts? Blatant, and multiple attempts with the same payloads. I usually get one a week, but got about 20 over the last couple. Perhaps it’s just that spam filters are not catching the bulk of them, but it looks like volume has jumped dramatically. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich on Pragmatic Key Management for Data Encryption. Favorite Securosis Posts Adrian Lane: Understanding and Selecting a Key Manager. Focused introduction – excellent post! Mike Rothman: Understanding and Selecting a Key Manager. The more cloudy things become, the more important encryption is going to be. This research is very important for the next few years. Other Securosis Posts Incite 10/17/2012: Passion. Defending Against DoS Attacks: the Process. Friday Summary: October 12, 2012. Favorite Outside Posts Rich: Hacked terminals capable of causing pacemaker deaths. We knew this was coming and the device manufacturers tried to pretend it wouldn’t happen. Now let the denials start. Dave Lewis: ‘Four horsemen’ posse: This here security town needs a new sheriff. David Mortman: Amazon’s Glacier cloud is made of… TAPE. It’s ‘elastic’, self service, and on demand. Mike Rothman: What an Academic Who Wrote Her Dissertation on Trolls Thinks of Violentacrez. A week ago, the worst troll on Reddit was outed. This guy portrays himself as a “regular guy.” Nonesense. Trolls are the scum of the earth. Web gladiators who are very tough behind the veil of anonymity. Read this article, where a person who did her dissertation on trolls weighs in. Adrian Lane: The Scrap Value of a Hacked PC, Revisited. This graphic works as a quick education on both the types of attacks a user might face, and why users are barraged with attacks. Project Quant Posts Malware Analysis Quant: Index of Posts. Malware Analysis Quant: Metrics – Monitor for Reinfection. Malware Analysis Quant: Metrics – Remediate. Malware Analysis Quant: Metrics – Find Infected Devices. Malware Analysis Quant: Metrics – Define Rules and Search Queries. Research Reports and Presentations The Endpoint Security Management Buyer’s Guide. Pragmatic WAF Management: Giving Web Apps a Fighting Chance. Understanding and Selecting Data Masking Solutions. Evolving Endpoint Malware Detection: Dealing with Advanced and Targeted Attacks. Implementing and Managing a Data Loss Prevention Solution. Defending Data on iOS. Top News and Posts General Dynamics Introduces NSA-Certified COTS Computer. The question is, would you or someone you know buy one? Netanyahu: Cyber attacks on Israel increasing. I want a digital Iron Dome too! With lasers and stuff. Wonder if they sell them on Think Geek? State-Sponsored Malware ‘Flame’ Has Smaller, More Devious Cousin. miniFlame. ‘Mass Murder’ malware. The Costs of the Cloud: Double-Check Me on This, Would You? Nitol Botnet Shares Code with Other China-Based DDoS Malware. PayPal’s Security Token Is Not So Secure After All. The token does not protect the user account from an attacker gaming the process, but that’s not really the value of the token to PayPal. Hackers Exploit ‘Zero-Day’ Bugs For 10 Months On Average Before They’re Exposed. Could Hackers Change Our Election Results? Microsoft Security Intel Report (PDF). Beating Automated SQL Injection Attacks. About the same as our WAF management recommendations. CallCentric hit by DDoS It’s the fashionable thing. Everyone’s doing it! Russian Anti-Virus Firm Plans Secure Operating System to Combat Stuxnet. For control systems? Yeah, good luck with that. Java Patch Plugs 30 Security Holes. Blog Comment of the Week Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week’s best comment goes to nobody, as we have

One of the things about celebrating a birthday is the inevitable reflection. You can’t help but ask yourself: “Another year has gone by – am I where I’m supposed to be? Am I doing what I like to do? Am I moving in the right direction?” But what is that direction? How do you know? Adam’s post at Emergent Chaos about following your passion got me thinking about my own journey. The successes, the failures, the opportunities lost, and the long (mostly) strange trip it’s been. If you had told me 25 years ago as I was struggling through my freshman writing class that I’d make a living writing and that I’d like it, I’m actually not sure what my reaction would have been. I could see laughter, but I could also see nausea. And depending on when I got the feedback from that witch professor on whatever crap paper I submitted, I may have smacked you upside the head. But here I am. Writing every day. And loving it. So you never can tell where the path will lead you. As Adam says, try to resist the paint by numbers approach and chase what you like to do. I’ve seen it over and over again throughout my life and thankfully was smart enough to pay attention. My Dad left pharmacy when I was in 6th grade to go back to law school. He’s been doing the lawyer thing for 30+ years now and he still is engaged and learning new stuff every day. And even better, I can make countless lawyer jokes at his expense. My father in law has a similar story. He was in retail for 20+ years. Then he decided to become a stock broker because he was charting stocks in his spare time and that was his passion. He gets up every day and gets paid to do what he’d do anyway. That’s the point. If what you do feels like work all the time, you’re doing something wrong. I can envision telling my kids this story and getting the question in return: “OK Mr. Smart Guy, you got lucky and found your passion. How do I find mine?” That’s a great question and one without an easy answer. The only thing I’ve seen work consistently is to do lots of things and figure out what you like. Have you ever been so immersed that hours passed that felt like minutes? Or seconds? Sure, if you could figure out how to play Halo professionally that would be great. But that’s the point – be creative and figure out an opportunity to make money doing what you love. That’s easier said than done but it’s a lot better than a sharp stick in the eye working for people you can’t stand doing something you don’t like. Adam’s post starts with an excerpt from Cal Newport’s Follow a career passion?, which puts a different spin on why folks love their jobs: The alternative career philosophy that drove me is based on this simple premise: The traits that lead people to love their work are general and have little to do with a job’s specifics. These traits include a sense of autonomy and the feeling that you’re good at what you do and are having an impact on the world. It’s true. At least it has been for me. But my kids and everyone else need to earn this autonomy and gain proficiency at whatever job they are thrust into. Which is why I put such a premium on work ethic. You may not know what your passion is, but you can work your tail off as you find it. That seems to be a pretty good plan. –Mike Photo credits: Passion originally uploaded by Michael @ NW Lens Heavy Research We’re 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. Defending Against Denial of Service (DoS) Attacks The Process Defense, Part 2: Applications Defense, Part 1: the Network Understanding and Selecting Identity Management for Cloud Services Introduction Securing Big Data Recommendations and Open Issues Operational Security Issues Incite 4 U It’s not groupthink. The problem is the checkbox: My pal Shack summarizes one of the talks he does at the IANS Forums in Infosec’s Most Dangerous Game: Groupthink. He talks about the remarkable consistency of most security programs and the controls implemented. Of course he’s really talking about the low bar set by compliance mandates, and how that checkbox mentality impacts how far too many folks think about security. So Dave busts out the latest management mental floss (The Lean Startup) and goes through some concepts to build your security program based on the iterative process used in a start-up. Build something, measure its success, learn from the data, and pivot to something more effective. It’s good advice, but be prepared for battle because the status quo machine (yea auditors, I’m looking at you) will stand in your when you try to do something different. That doesn’t mean it’s not the right thing to do, but it will be harder than it should. – MR Android gone phishin’: There’s always a lot of hype around mobile malware, in large part because AV vendors are afraid people won’t remember to buy their mobile products without a daily reminder of how hosed they are. (I kid). (Not really.) As much as I like to minimize the problem, mobile malware has been around for a while, but it tends to be extremely platform and region specific. For example, it’s a bigger deal in parts of Europe and Asia than North America, and until recently was very Symbian heavy. Now the FBI warns of phishing-based malware for Android. It’s hard to know the scope of the problem based on a report like

Between new initiatives like cloud computing, and new mandates due to the continuous onslaught of compliance, managing encryption keys is moving from something only big banks worried about to something popping up among organizations of all sizes and shapes. Whether it is to protect customer data in a new web application or to ensure that a lost backup tape doesn’t force you to file a breach report, more and more organizations are encrypting more data in more places than ever before. And tying all of this together is the ever-present shadow of managing all those keys. In our Pragmatic Key Management for Data Encryption paper we highlighted some of the sins of the past that made key management painful, but showed how new strategies and tools can cut through those roadblocks to make key management a much more (for lack of a better word) manageable process. In the paper we identified four strategies for data encryption key management: Manage keys locally. Manage keys within a single application stack with a built-in key management feature. Manage keys for a silo using an external key management service/server/appliance, separate from the data and application stacks. Coordinate management of most or all keys across the enterprise with a centralized key management tool. We called these local, application stack, silo, and enterprise key management. Of those four strategies, the last two introduce a dedicated tool for key management. This series (and the eventual paper) will dig in to explain the major features and functions of a key manager, what to look for, and how to pick one that best fits your needs. *Why use a key manager?** Data encryption can be a tricky problem, especially at scale. Actually, all cryptographic operations can be tricky, but to keep our focus we will limit ourselves to encrypting data rather than digital signing, certificate management, and other uses of cryptography. The more diverse your keys, the better your security and granularity, but the higher the complexity. While rudimentary key management is built into a variety of products – including full disk encryption, backup tools, and databases – at some point many security professionals find they need a little more power than what’s embedded in the application stack. Some of the needs include: More robust reporting (especially for compliance). Better administrator monitoring and logging. Flexible options for key rotation and expiration. Management of keys across application components. Stronger security. Or sometimes, as with custom applications, there isn’t any existing key management to lean on. In these cases it makes sense to start looking at a dedicated key manager. In terms of use cases, some of the sweet spots we’ve found include: Backup encryption, due to a mix of longevity needs and very limited key management implementations in backup products themselves. Database encryption, because most database management systems only include the most rudimentary key management, and rarely the ability to centrally manage keys across different database instances or segregate keys from database administrators. Application encryption, which nearly always relies on a custom encryption implementation and, for security reasons, should separate key management from the application itself. Cloud encryption, due to the high volume of keys and variety of deployment scenarios. This is just to provide some context – many of you reading this probably already know you need a dedicated key manager. If you want more background on data encryption key management and when to move on to this category of tools you should read our other paper first, then hop back to this one. For the rest of you, the remaining posts in the series will cover technical features, management features, and how to choose between products. Share: