Research

Now that you have a better understanding of major key manager features and options we can spend some time outlining the selection process. This largely comes down to understanding your current technical and business requirements (including any pesky compliance requirements), and trying to plan ahead for future needs. Yes, this is all incredibly obvious, but with so many different options out there – from HSMs with key management to cloud key management services – it’s too easy to get distracted by the bells and whistles and miss some core requirements. Determine current project requirements Nobody buys a key manager for fun. It isn’t like you find yourself with some spare budget and go, “Hey, I think I want a key manager”. There is always a current project driving requirements, so that’s the best place to start. We will talk about potential future requirements, but never let them interfere with your immediate needs. We have seen projects get diverted or derailed as the selection team tries to plan for every contingency, then buys a product that barely meets current needs, which quickly causes more major technical frustration. List existing systems, applications, and services involved: The best place to start is to pull together a list of the different systems, application stacks, and services that need key management. This could be as simple as “Oracle databases” or as complex as a list of different databases, programming languages used in applications, directory servers, backup systems, and other off-the-shelf application stacks. Determine required platform support: With your list of systems, applications, and services in hand; determine exactly what platform support you need. This includes which programming languages need API support, any packaged applications needing support (including versions), and even potentially the operating systems and hardware involved. This should also include encryption algorithms to support. Be as specific as possible because you will send this list to prospective vendors to ensure their product can support your platforms. Map out draft architectures: Not only is it important to know which technical platforms need support, you also need an idea of how you plan on connecting them to the key manager. For example there is a big difference between connecting a single database to a key manager in the same data center, and supporting a few hundred cloud instances connected back to a key manager in a hybrid cloud scenario. If you plan to one or more key managers in an enterprise deployment, with multiple different platforms, in different locations within your environment, you will want to bee sure you can get all the appropriate bits connected – and you might need features such as multiple network interfaces. Calculate performance requirements: It can be difficult to accurately calculate performance needs before you start testing, but do your best. The two key pieces to estimate are the number of key operations per second and your network requirements (both speed and number of concurrent network connections/sockets). If you plan to use a key manager that also performs cryptographic operations include those performance requirements. List any additional encryption support required: We have focused almost exclusively on key management, but as we mentioned some key managers also support a variety of other crypto operations. If you plan to use the tool for encryption, decryption, signing, certificate management, or other functions; make a list and include any detailed requirements like the ones above (platform support, performance, etc.). Determine compliance, administration, reporting, and certification requirements: This is the laundry list of any compliance requirements (such as which operations require auditing), administrative and systems management features (backup, administrator separation of duties, etc.), reporting needs (such as pre-built PCI reports), and certifications (nearly always FIPS 140). We have detailed these throughout this series, and you can use it as a guide when you build your checklist. List additional technical requirements: By now you will have a list of your core requirements but there are likely additional technical features on your required or optional list. And last but not least spend some time planning for the future. Check with other business units to see if they have key management needs or are already using a key manager. Talk to your developers to see if they might need encryption and key management for an upcoming project. Review any existing key management, especially in application stacks, that might benefit from a more robust solution. You don’t want to list out every potential scenario to the point where no product can possibly meet all your needs, but it is useful to take a step back before you put together an RFP, to see if you can take a more strategic approach. Write your draft RFP Try to align your RFP to the requirements collected above. There is often a tendency to ask for every feature you have ever seen in product demos, but this frequently results in bad RFP responses that make it even harder to match vendor responses against your priorities. (That’s a polite way of saying that an expansive cookie-cutter RFP request is likely to result in a cookie-cutter response rather than one tailored to your needs). Enough of the soapbox – let’s get into testing. Testing Integrating a key manager into your operations will either be incredibly easy or incredibly tricky, depending on everything from network topography to applications involved to overall architecture. For any project of serious scale it is absolutely essential to test compatibility and performance before you buy. Integration Testing The single most crucial piece to test is whether the key manager will actually work with whatever application or systems you need to connect it with. Ideally you will test this in your own environment before you buy, but this isn’t always possible. Not all vendors can provide test systems or licenses to all potential customers, and in many situations you will need services support or even custom programming to integrate the key manager. Here are some suggestions and expectations for how to test and minimize your risk: If you are deploying the

As I boarded the bus, which would take me to the train, which would take me into NYC to work my engineering co-op job at Mobil Oil, I had plenty of time to think. I mostly thought about how I never wanted to be one of those folks who do a 75-90 minute commute for 25 years. Day in, day out. Take the bus to the train to the job. Leave the job, get on the train and get home at 7 or 8 pm. I was 19 at the time. I would do cool and exciting things. I’d jet around the world as a Captain of Industry. Commuting in my suit and tie was not interesting. No thanks. Well, it’s 25 years later. Now I can appreciate those folks for who they were. They were grinders. They went to work every day. They did their jobs. Presumably they had lives and hobbies outside work. After 20-something years in the workforce, I have come to realize it is a grind even if I don’t have a commute and I do jet around the world, working on interesting problems and meeting interesting people. But it’s still a grind. And it’s not just work where you have to grind. After almost a decade wrangling 3 kids, that’s a grind too. Get them to activities, help with homework and projects, teach them right from wrong. Every day. Grind it out. But here’s the thing. I viewed those salarymen taking the bus to the train every day as faceless automatons, just putting in their time and waiting to die. But for some activities, being a grind doesn’t make them bad. And grinding doesn’t have to make you unhappy. In order to have some semblance of contentment, and dare I say, happiness, you need to learn to love the grind. It’s a rare person who has exciting days every day. The folks who can do what they want and be spontaneous all the time are few and far between. Or lucky. Or born into the right family… so still lucky. The rest of us have responsibilities to our loved ones, to our employers, to ourselves. Again, that doesn’t mean some days the grind doesn’t get the better of me. That’s part of the deal. Some days you beat the grind, other days the grind beats you. So you get up the next day and grind some more. At some point, you appreciate the routine. At least I do. I have been fortunate enough to travel the world – mostly for work. I have seen lots of places. Met lots of people. I enjoy those experiences, but there is something about getting up in my own bed and getting back to the grind that I love. The grind I chose. And the grind changes over time. At some point I hope to spend less time grinding for a job. But that doesn’t mean I’ll stop grinding. There is always something to do. Though I do have an ulterior motive for grinding day in and day out. I can’t make the case to my kids about the importance of the work ethic unless I do it. They need to see me grinding. Then they’ll learn to expect the grind. And eventually to love it. Because that’s life. –Mike PS: Happy 12/12/12. It will be the last time we see this date for 100 years. And then it will be in the year 2112, and Rush will finally have their revenge… Photo credits: Angle Grinder originally uploaded by HowdeeDoodat 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 Deploying the EWS Determining Urgency Understanding and Selection an Enterprise Key Manager Management Features Newly Published Papers Implementing and Managing Patch and Configuration Management 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 Responsible agonizing: I don’t expect us to ever reach consensus on the disclosure debate. There are far too many philosophical and religious underpinnings, mired in endless competing interests, for us to ever agree. What’s responsible to one party always looks irresponsible to another, and even the definition of responsible changes with the circumstances. That’s why I am so impressed with Cody Brocious (Daeken)’s heartfelt discussion of his thought process and the implications of his disclosure this summer of a serious vulnerability in hotel locks. For those not following the story, Cody devised a way to easily unlock a particular lock model widely used in hotels, with under $50 in hardware. He discovered it years ago but only made it public this summer. A few weeks ago criminals were discovered using his technique for real world theft and the manufacturer subsequently had to open up a massive, very expensive, response. Cody weighs his thoughts on his decision to disclose and the consequences. Whatever your disclosure beliefs, this is the kind of thought and focus on customers/users that we should not only hope for, but expect. – RM How much information is enough? Early in my career as a network analyst product differentiation was generally based on speeds and feeds. My thing is bigger than your thing, so you should buy it. We still see that a bit in network security, but as we move towards understanding the value of security and threat intelligence (check out the Early Warning series to learn more) I wonder how big is big enough. Over on the Risk I/O blog they talk about crowdsourcing vulnerability intelligence, but it’s really about aggregating information to determine activity patterns. Once you reach a certain point, does it really matter whether a vendor or service provider fields 5 billion or