Research

It’s one thing to collect, secure, and track a wide range of keys; but doing so in a useful, manageable manner demonstrates the differences between key management products. Managing disparate keys from distributed applications and systems, for multiple business units, technical silos, and IT management teams, is more than a little complicated. It involves careful segregation and management of keys; multiple administrative roles; abilities to organize and group keys, users, systems, & administrators; appropriate reporting; and an effective user interface to tie it all together. Role management and separation of duties If you are managing more than a single set of keys for a single application or system you need a robust role-based access control system (RBAC) – not only for client access, but for the administrators managing the system. It needs to support ironclad separation of duties, and multiple levels of access and administration. Role management and separation of duties An enterprise key manager should support multiple roles, especially multiple administrative roles. Regular users never directly access the key manager, but system and application admins, auditors, and security personnel may all need some level of access at different points of the key management lifecycle. For instance: A super-admin role for administration of the key manager itself, with no access to the actual keys. Limited administrator roles that allow access to subsets of administrative functions such as backup and restore, creating new key groups, and so on. An audit and reporting role for viewing reports and audit logs. This may be further subsetted to allow access only to certain audit logs (e.g., a specific application). System/application manager roles for individual systems and application administrators who need to generate and manage keys for their respective responsibilities. Sub-application manager roles which only have access to a subset of the rights of a system or application manager (e.g., create new keys only but not view keys). System/application roles for the actual technical components that need access to keys. Any of these roles may need access to a subset of functionality, and be restricted to groups or individual key sets. For example, a database security administrator for a particular system gains full access to create and manage keys only for the databases associated with those systems, but not to manage audit logs, and no ability to create or access keys for any other applications or systems. Ideally you can build an entitlement matrix where you take a particular role, then assign it to a specific user and group of keys. Such as assigning the “application manager” role to “user bob” for group “CRM keys”. Split administrative rights There almost always comes a time where administrators need deeper access to perform highly-sensitive functions or even directly access keys. Restoring from backup, replication, rotating keys, revoking keys, or accessing keys directly are some functions with major security implications which you may not want to trust to a single administrator. Most key managers allow you to require multiple administrators to apporve for these functions, to limit the ability of any one administrator to compromise security. This is especially important when working with the master keys for the key manager, which are needed for taks including replication and restoration from backup. Such functions which involve the master keys are often handled through a split key. Key splitting provides each administrator with a portion of a key, all or some of which are required. This is often called “m of n” since you need m sub-keys out of a total of n in existence to perform an operation (e.g., 3 of 5 admin keys). These keys or certificates can be stored on a smart card or similar security device for better security. Key grouping and segregation Role management covers users and their access to the system, while key groups and segregation manage the objects (keys) themselves. No one assigns roles to individual keys – you assign keys to groups, and then parcel out rights from there (as we described in some examples above). Assigning keys and collections of keys to groups allows you to group keys not only by system or application (such as a single database server), but for entire collections or even business units (such as all the databases in accounting). These groups are then segregated from each other, and rights are assigned per group. Ideally groups are hierarchical so you can group all application keys, then subset application keys by application group, and then by individual application. Auditing and reporting In our compliance-driven security society, it isn’t enough to merely audit activity. You need fine-grained auditing that is then accessible with customized reports for different compliance and security needs. Type of activity to audit include: All access to keys All administrative functions on the key manager All key operations – including generating or rotating keys A key manager is about as security-sensitive as it gets, and so everything that happens to it should be auditable. That doesn’t mean you will want to track every time a key is sent to an authorized application, but you should have the ability for when you need it. Some tools support Reporting Raw audit logs aren’t overly useful on a day to day basis, but a good reporting infrastructure helps keep the auditors off your back while highlighting potential security issues. Key managers may include a variety of pre-set reports and support creation of custom reports. For example, you could generate a report of all administrator access (as opposed to application access) to a particular key group, or one covering all administrative activity in the system. Reports might be run on a preset schedule, emailing summaries of activity out on a regular basis to the appropriate stakeholders. User interface In the early days of key management everything was handled using command line interfaces. Most current systems implement graphical user interfaces (often browser based) to improve usability. There are massive differences in look and feel across products, and a GUI that fits the workflow of your staff can save a great

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:

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

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:

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:

Rich here. If memory serves, I completed my first First Aid/CPR certification when I was around 10. I followed up with lifeguard at 16, ensuring myself a few years of employment as a seasonal professional volleyball player. I completed my EMT and 19 after being dumped by my first girlfriend, when I needed a way to occupy my free time. For some reason it’s hard to get insurance for 19 year-old-males driving things with lights and sirens, so I didn’t get onto my first fire department or ambulance company until I was nearly 21. I followed that up with paramedic at 22, and since then have been trained, worked as, and/or certified in everything from dive rescue, mountain rescue, and ski patrol to WMD and national disaster medical response. That’s over 20 years of being an active emergency responder at the professional level, and 25 if you count sitting in a chair, getting sunburned, and pretending I was cool like on Baywatch (well, after Baywatch started). So I am struggling to deal with the fact that as the CEO of a startup and the father of 2.4 young children, my response days are probably on hold for a bit. My EMT expired a few months ago and I don’t have the time to go to a refresher class. This is the second time since I was 19 I have let it drop, the previous time also when I was busy as heck at work. I’m still technically on a federal response team, but without my EMT they are looking at slotting me into IT… where my job will be to fix people’s computers. I. Cannot. Handle. That. Besides, I can’t take off for the minimum 2-3 week deployments anymore. Giving up part of your identity, for however short a period, is never easy. Not to pick on people who dally with their EMT on weekends, but I worked On The Job at the full-time professional level, and have been in emergency services a lot longer than IT. Heck, my computer was a Commodore 128 when I first started in EMS. I would have killed for an iPhone and iPad to fill the hours on some of the slower shifts. “Siri – calculate the drip rate for digoxin on a 172 lb patient with rapid atrial fibrilation” “Let me find that for you Rich… Willie Davis played center field for the 1972 Dodgers” “No dammit, he’s dying!” “Now playing ‘Staying Alive’ by the Bee Gees” Maybe that wouldn’t have been so good. I can live without the lights and sirens, but I miss being an active part of the community. I miss cooking meals in the firehouse, drinking Crown Royal on the rocks in the locker room after a cold ski patrol shift, or simply bullshitting for hours on end with my partner in the ambulance parked on the street corner. Yes, there was the bad, but my kids puke on me far more than any patients ever did. But never underestimate the appeal of the Brotherhood. But I’m co-running a successful company and a happy family. There is absolutely no way I can balance the needs of those priorities with the demands of even a volunteer responder position. I try to be honest with myself, and the truth is I haven’t really been active since we had our first daughter. I could try and cling, but all I’d do is be bad at everything. So it’s time for a break. At some point work will settle down and the kids will be okay with Dad being gone for a shift every now and then. I’ll need to redo a lot of training, but there’s nothing wrong with that. And I’ll still totally abuse my background and use firefighting and rescue anecdotes in every presentation I can stuff them into. Thanks for letting me vent. I love a semi-captive audience. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Nothing I could find. No one loves us any more. Favorite Securosis Posts Adrian Lane: US Returns Fire in Huawei/ZTE Report. I’ve picked this as Fav internal, both for Rich identifying the pressure point as well as Huawei will be in the news for a long time. It’s not just the U.S. reaction, but about a dozen other countries and about half the firms that work with Huawei have made similar claims. Rich: Defending Against DoS Attacks: Defense Part 1, the Network. I got crap for seeming to dismiss the recent DoS attacks. It wasn’t that I dismissed their importance, but not everyone is in the same crosshairs. DDoS has been a problem for a while but we see a massive uptick in interest, for very valid reasons. Other Securosis Posts Defending Against DoS Attacks: Defense, Part 2: Applications. Incite 10/10/2012: A Perfect Day. Favorite Outside Posts Adrian Lane: Designing for failure may be the key to success. You need to be a database and language processing geek to appreciate this, but IBM Fellow Bruce Lindsey clearly sees the inner workings of data processing systems and how all the pieces fit together. Not for everyone, but an interesting view on designing software for unexpected outcomes. Rich: Spaf on the anti-science side of political rhetoric. I’m bordering on getting political by linking to this, but the important part for me is the importance of science and critical thinking. 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. Malware Analysis Quant Report. Top News and Posts Prepaid Enters Mainstream. Trying to find the consumer benefit here – I see a medium open to fraud and fees at consumers’ expense. Speaking of Huawei, hacker shows ease of gaining router access. Thousands of student records stolen in Florida breach. Google patches Chrome within 24 hours of bug

I had a call today with a Reuters reporter about the Huawei/ZTE deal being spiked by the US government. To be honest, there’s an aspect of this story I assumed someone else would mention first, but I haven’t noticed it being explicitly stated anywhere yet. It’s a simple story: China hacks the crap out of the rest of the world. The world doesn’t do dick, due to a lack of real ability to apply meaningful consequences. Big Chinese business wants to expand globally. US (and probably the rest of the world) says “Ah ha!” I don’t know if Huawei and ZTE are a real risk, rather than a potential security risk (which they certainly are), but it doesn’t matter. This is all about consequences, and no one in the US government gives a crap if Huawei gets caught in the middle. In fact it would be awfully nice if those executives pressured their own government to back down. The real risk of the Huawei/ZTE deals don’t matter at this point – it’s all about what few consequences the US can create for the Chinese government. Share:

There was a lot of big news this week in the security world, most of it bad. Even if you skip the intro, make sure you read the Top News section. Rich here, Growing up I was – and this might shock some of you – a bit of a nerd. I glommed onto computers and technology pretty much as soon as I had access to them, and when I didn’t I was reading books and watching shows that painted wonderful visions of the future. I was a hacker before I ever heard the word, constantly taking things apart to see how they worked, then building my own versions. Technology is thus very intuitive to me. I never had to learn it in the same way as people coming to computers and electronics later in life. I began programming so early in life that it keyed into the same (maybe) brain pathways that allow children to learn multiple languages with far more facility than adults. While my generational peers are far more comfortable with technology and computers than our parents, I generally still have a leg up due to my early immersion. I naturally assumed that the generations following me would grow up closer to my experiences than my less geeky peers. But much to my surprise, although they are very comfortable with computers, they don’t have the damnedest idea of how they work or how to bend them to their own will. Unless it involves cats and PowerPoint. Lacking teachers who understood tech, they grow up learning how to use Office, not to program or dig into technology beyond the shallowest surface levels. As I have started raising my own kids, I worry about how to get them interested in technology, and algorithmic thinking, in a world where iPads put the entire Disney repository a few taps away. I’m not talking about forcing them to become programmers, but taking advantage of their brain plasticity to reinforce logical thinking and problem solving, and at least convey a sense of deeper exploration. This really did worry me, but over the past few months I have realized that as a parent I have the opportunity to engage my children to degrees my parents couldn’t possibly imagine. It was a big deal when I got my first Radio Shack electronics kit. It was even a bigger deal when I made my first radio. My kids? This past weekend my 3.5 and 2 year old got to play with their first home-built LEGO robot. Yes, I did most of the building and all the programming, but I could see them learning the foundation of how it worked and what we could make it do. Building a robot to play with our cat is a hell of a lot more exciting than putting a picture of a cat in a PowerPoint. This is barely the start. I grew up pushing ASCII pixels on screens. They will grow up programming, and perhaps designing, autonomous flying drones with high-definition video feeds. I grew up making simple electric candles that would turn on in a dark room. They will be able to create wonderful microcontroller-based objects they then embed into 3-D printed housings. There’s no guarantee they will actually be interested in these things, but social engineering isn’t just for pen testing. Hopefully I can manipulate the crap out of them so they at least get the basics. And, if not, it means more stock fab material for me. I’m biased. I think most of my success in life is due to a combination of logical thinking, the exploratory drive of a hacker, and a modest facility with the written word. As a parent I now have tools to teach these skills to my children in ways our parents could only dream about. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich quoted on the myth of cyberinsurance. Mike’s Security Intelligence post at Dark Reading. Favorite Securosis Posts Adrian Lane: My Security Fail (and Recovery) for the Week. Gave me a moment of panic. Mike Rothman: Securing Big Data: Architectural Issues. This series is critical for you to learn what’s coming. If it hasn’t already arrived. Rich: David Mortman’s Another Inflection Point. The more we let go of, the more we can do. Other Securosis Posts Defending Against DoS Attacks: The Attacks. Incite 9/27/2012: They Own the Night. New Research Paper: Pragmatic WAF Management. Favorite Outside Posts Adrian Lane: OAuth 2.0 – Google Learns to Crawl. For someone learning just how much I don’t know about authorization, this is a good overview of the high points of the OAuth security discussion. Mike Rothman: 25 Great Quotes from the Princess Bride. 25 YEARS! WTF? I don’t feel that old, but I guess I am. Take a trip down memory lane and remember one of the better movies ever filmed. IMHO, anyway. Rich: Connect with your inner grey hat. The title is a bit misleading, but the content is well stated. You need to change up your thinking constantly. Research Reports and Presentations 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. Malware Analysis Quant Report. Report: Understanding and Selecting a Database Security Platform. Top News and Posts The big news this week is the compromise and use of an Adobe code signing certificate in targeted attacks. Very serious indeed. Banks still fighting off the Iranian DDoS attacks. OpenBTS on Android. This is the software you use to fake a cell phone base tower. Smart grid control vendor hacked. Yes, they had deep access to their clients, why do you ask? An interview with the author of XKCD. Sudo read this article. PHPMyadmin backdoored. PPTP now really and truly dead. More Java 0day. Seriously, what the hell is going on this week? And to top everything off, a Sophos post

I remember sitting at lunch with a friend and well-respected member of our security community as I described the architecture we used to protect our mail server. I’m not saying it’s perfect, but this person responded with, “that’s insane – I know people selling 0-days to governments that don’t go that far”. On another occasion I was talking with someone with vastly more network security knowledge and experience than me; someone who once protected a site attacked daily by very knowledgeable predators, and he was… confused as to why I architected the systems like I did. Yesterday, it saved my ass. Now I’m not 100% happy with our current security model on mail. There are aspects that are potentially flawed, but I’ve done my best to reduce the risk while still maintaining the usability we want. I actually have plans to close the last couple holes I’m not totally comfortable with, but our risk is still relatively low even with them. Here’s what happened. Back when we first set up our mail infrastructure we hit a problem with our VPN connections. Our mail is on a fully segregated network, and we had some problems with our ISP and IPSec-based VPNs even though I tried multiple back-end options. Timing-wise we hit a point where I had to move forward, so I set up PPTP and mandated strong passwords (as in I reviewed or set all of them myself). Only a handful of people have VPN access anyway, and, at the time, a properly-constructed PPTP password was still very secure. That delusion started dying this summer, and was fully buried yesterday thanks to a new, cloud-based, MS-CHAP cracking tool released by Moxie Marlinspike and David Hulton. The second I saw that article I shut down the VPN. But here’s how my paranoia saved my ass. As a fan of hyper-segregation, early on I decided to never trust the VPN. I put additional security hardware behind the VPN, with extremely restrictive policies. Connecting via the VPN gave you very little access to anything, with the mail server still completely walled off (a UTM dedicated only to the mail server). Heck, the only two things you could try to hack behind the VPN were the VPN server itself and the UTM… nothing else is directly connected to that network, and all that traffic is monitored and filtered. When I initially set things up people questioned my choice to put one security appliance behind another like that. But I didn’t want to have to rely on host security for the key assets if someone compromised anyone connected to our VPN. In this case, it worked out for me. Now I set all this up pre-cloud, but you can set up a similar architecture in many VPC or private cloud environments (you need two virtual NICs and a virtual UTM, although even simple firewall rules can go a long way to help). This is also motivation to finish the next part of my project, which involves yet another UTM and server. Share: