Research

Well, this is embarrassing: Blowing hash and signing functions so that the underlying code can be changed without the hash and sigs changing is horrifyingly atrocious. This is the code equivalent of impersonating a person with a mask so good nobody, not even the real person themselves, can tell the difference. … Google espouses 60 days to fix exploitable bugs and going public one week after private notification. According to Bluebox they told Google about this via bug 8219321 in February 2013. That’s a little bit more than 60 days ago. Seeing as it’s now July, I think (and I’m not very good at math, so bear with me here) that’s at least twice as many. It’s especially more than 7 days. I’m not sure how Google are following their own disclosure policy. I suspect the people motivated to publish Google’s disclosure policy were all or mostly on the web side. It is a much different problem when you are dealing with software updates, especially on a platform that often you cannot update. I have yet to find a ROM past Android 4.0 (current is 4.2) that I can get running on my test phone. HTC certainly isn’t providing it, which means many millions of phones will be vulnerable… forever. There was little doubt that publishing that policy wouldn’t eventually haunt them. Share:

An OpenStack Security Guide epub was released this week, and among the contributors was our friend Andrew Hay. Trying to find this info before was like locating a piece of hay in a haystack (not an Andrew Hay – he would be considerably easier to find in a haystack). We use OpenStack for the Cloud Security Alliance training labs, and I had to figure out a lot of this myself through painful reading of barely-legible documentation. The book was created in a 5-day sprint so it’s a little rough. Some sections are pretty light but they intend to improve it over time. The sections on hardening the Keystone identity service, picking a hypervisor, hardening core services such as the message queue, and secure networking, are pretty decent. You can’t secure OpenStack just by reading this – you need to understand the platform first – but this guide will definitely point you in the right directions. Share:

The FTC has issued new rules on data collection for minors: Now, the list of what counts as “personal information” has been expanded to include geolocation markers, IP addresses, pictures or audio of the child, and persistent cookies that can track users across sites. The rules also now apply to companies that make plug-ins or advertising networks, which often collect information but aren’t thought of as discrete sites that fall under the rules. I’m pulling my kids from daycare and having them do all my browsing. Then I can sue Google and anyone else who tracks me them. Share:

One of our favorite friends, Jack Daniels, has a new post on Active Defense: If you make the claim that “active defense” is only a euphemism for “hacking back”, you are either hyping an agenda, or selling a (probably outdated) security model. Or perhaps you’ve just been misled by the previously mentioned shysters. By my count that’s three flavors of wrong, although one may be slightly less bitter. … Let’s start with “active defense”. It is not a new idea, and it doesn’t necessarily mean hacking back. It may encompass counterattacks, but there are a lot of active defenses far short of attack. I refer you back to my post on active defense definitions last summer. I really don’t know where all the confusion is coming from – I meet almost no security professionals who don’t understand the difference. It seems to be more of a press/PR issue. Share:

Our schedules are already filling up for Black Hat this year, so if you want to meet please drop us a line. And for those who want a real schedule, [James Arlen put one together for easy import into your calendar].(https://www.google.com/calendar/ical/f9lvmur9pjc2r1oi7psi3li40s%40group.calendar.google.com/public/basic. Share:

Apple posted a page with some short details on the new business features of iOS 7. These security enhancements actually change the game for iOS security and BYOD: Data protection is now enabled by default for all applications. That means apps’ data stores are encrypted with the user passcode. For strongish passphrases (greater than 8 characters is a decent start) this is very strong security and definitely up to enterprise standards if you are on newer hardware (iPhone 4S or later, for sure). You no longer need to build this into your custom enterprise apps (or app wrappers) unless you don’t enforce passcode requirements. Share sheets provide the ability to open files in different applications. A new feature allows you, through MDM I assume, to manage what apps email attachments can open in. This is huge because you get far greater control of the flow on the device. Email is already encrypted with data protection and managed through ActiveSync and/or MDM; now that we can restrict which apps files can open in, we have a complete, secure, and managed data flow path. Per-app VPNs allow you to require an enterprise app, even one you didn’t build yourself, to use a specific VPN to connect without piping all the user’s network traffic through you. To be honest, this is a core feature of most custom (including wrapped) apps, but allowing you to set it based on policy instead of embedding into apps may be useful in a variety of scenarios. In summary, some key aspects of iOS we had to work around with custom apps can now be managed on a system-wide level with policies. The extra security on Mail may obviate the need for some organizations to use container apps because it is manageable and encrypted, and data export can be controlled. Now it all comes down to how well it works in practice. A couple other security bits are worth mentioning: It looks like SSO is an on-device option to pass credentials between apps. We need a lot more detail on this one but I suspect it is meant to tie a string of corporate apps together without requiring users to log in every time. So probably not some sort of traditional SAML support, which is what I first thought. Better MDM policies and easier enrollment, designed to work better with your existing MDM tools once they support the features. There are probably more but this is all that’s public now. The tighter control over data flow on the device (from email) is unexpected and should be well received. As a reminder, here is my paper on data security options in iOS 6. Share:

If you see any of these in a vendor sales/analyst presentation, run fast. They open with, “this is under NDA” or “this is confidential” and you have never signed an NDA. The word “unique”. Especially in the same sentence as “industry leader”. If you are unique, you are, by definition, both the leader and the worst piece of crap out there. You do not want to be Schroedinger’s cat; it never ends well. No screenshots of the product until slide 43, addendum 7, behind a slide that says, “stairs out, beware of tiger”. No slides describing how the technology works. Bonus points if they won’t tell you because a) they are in stealth mode, b) it is a trade secret, or c) their investors won’t let them talk about it until the patent is issued (expected August 12, 2046). How you see the industry or world. Just tell us what problem you solve – we decide whether it is more important than the other 274 items on our to-do list. Bonus points if you refuse to skip this section when asked. A slide of company logos you aren’t supposed to put on slides because it violates your contract. Always amusing when the same logo is in every competitor’s slide decks as well. Any reference to Katrina, Pearl Harbor, or 9/11. Use chaff if they append “digital” to any of those words. We stop the APTs. (Some grammar fails are worse than others). The term “insider threat”, unless you sell to prisons or proctologists. Any reference to Edward Snowden, Unless you are actually the NSA (or Booze Allen, but for other reasons). I’m not trying to slam any vendor, and for the most part both the product people and the smart marketing execs I spend most of my time with roll their eyes at all of this as well, but man, it sure is happening a lot lately. Share:

I was talking to yet another contact today who reinforced that almost no one is sniffing SSL traffic when they deploy DLP. That means… No monitoring of most major webmail providers. No monitoring of many social networks. No monitoring of Dropbox or other cloud storage services. No monitoring of connections to any site that requires a login. Don’t waste your money. If you aren’t going to use DLP to monitor SSL/TLS encrypted web traffic you might as well stick to email, endpoint, or other channels. I’m sure no one will siphon off sensitive stuff to Gmail. Nope, never happens. Especially not after you block USB drives. Share:

I am intensely lazy. If you read anything by Tim Ferris (the “4 Hour X” guy), you have heard him talk about Minimum Effective Dose. What is the least you can do to achieve your objective? In some ways that’s how I define my life. Not that I am above hard work. You don’t swim/bike/run for 3-4 hours, climb mountains, hike the back bowls, or participate in intense all-day rescues without a little hard work. Sometimes I even enjoy getting my hands dirty – especially since I started spending most of my time at a desk. In other words, if something interests me, I’m all on it. But if it isn’t fun to me in some way, I will do everything in my power to minimize the time I need to spend on it. I’m on my third robot vacuum (A Neato, which is like a Cylon compared to the mousebot that is iRobot), pay a landscaper, have hired someone to clean my garage, and even confused a handyman I used to install some home automation switches (I like the programming – just not shocking the crap out myself because I’m too lazy to walk outside and hit the breaker). I relatively recently subscribed to FancyHands so I can email off requests to format papers, call various services that otherwise put you on hold for an hour, or research the nearest Mexican food to my current hotel. So I am really digging all the new automation options with cloud computing and our new API-driven world. This week I have been working on using Chef for security and figuring out the interplay between Chef and Amazon Web Services or OpenStack to enhance security automation. Most of this is to have some advanced material on hand for our Black Hat cloud security class next month, but the fact that I am putting the work in probably means we will end up with one of those classes where nobody groks command lines. The first add-on will be using Chef and OpsWorks to 1-click build out the secure demo application stack we put together for the labs, and push patches out to hundreds of systems with a second click (not that we will run hundreds – that might annoy Accounts Payable). If I have enough time I may have a Ruby app that simultaneously connects to AWS and Chef and monitors for any instances not managed by Chef, and instantly quarantines them and identifies the owner. (I have the pseudocode worked out but haven’t programmed Ruby much, so that will take some time.) Those are just two simple examples of integrating security automation. It wouldn’t be hard to extend the tool to automatically run vulnerability scans (randomly or after patch pushes), then use Chef to auto-patch noncompliant systems, and then kick off a report. You could even spin up a pen-testing instance inside the same Security Group, run a scan, send off the results, and shut it down automatically on completion. Heck, even these ideas are just scratching the surface. This kind of automation is powerful. If properly set up, it becomes extremely difficult for admins or developers to run anything that violates security policies. But it is a different way of thinking and requires different architectures so important things don’t go down when the Software Defined Security breaks them. Which it will – that’s what we actually want it to do. Anyway, I now need to go learn the absolute minimum amount of Chef and Ruby to hack together my demonstrations, and I’m about two weeks behind schedule. I might need to go outsource some of this to save myself some time… On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich at Macworld on Apple’s security design approach. Rich at Dark Reading on security design. Noticing a trend? Mike at Dark Reading on bug bounties (before the big Microsoft announcement – nice timing!). Talking Head Alert: Adrian on Key Management. Favorite Securosis Posts Adrian Lane: Microsoft Offers Six Figure Bounty for Bugs. Blue Hat Bug Bounties for Big Coin. Nice! Rich: Network-based Malware Detection 2.0: Deployment Considerations. Great series. Other Securosis Posts Scamables. How China Is Different. Security Analytics with Big Data: Deployment Issues. Project Communications. API Gateways: Access Provisioning. Favorite Outside Posts Adrian Lane: Edge Services in the Cloud. Open source tools for building out client services in a massively scalable way. Look at the request lifecycle and you will probably get an idea of how security would be implemented as a series of HTTP filters. You can even ‘canary’ test specific users onto different code, perhaps routing to an intrusion deception model… This is some very cool stuff! Rich: Dealing with eventual consistency in the AWS EC2 API. As we move into Software Defined Security, these sorts of issues will really annoy the f### out of us. Rich (2): Had to add this one: I ain’t in Kansas anymore… The real world is tough. Dave Lewis: Sr. Information Security Analyst. Take Dave’s old job! Research Reports and Presentations Email-based Threat Intelligence: To Catch a Phish. Network-based Threat Intelligence: Searching for the Smoking Gun. Understanding and Selecting a Key Management Solution. Building an Early Warning System. Implementing and Managing Patch and Configuration Management. Defending Against Denial of Service (DoS) Attacks. Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments. Tokenization vs. Encryption: Options for Compliance. Pragmatic Key Management for Data Encryption. The Endpoint Security Management Buyer’s Guide. Top News and Posts Harvard Business Review Posts Terrible Advice for CEOs on Information Security. Yahoo’s Very Bad Idea to Release Email Addresses. US, Russia to install “cyber-hotline” to prevent accidental cyberwar. Scores of vulnerable SAP deployments uncovered. Zeus Money Mule Recruiting Scam Targets Job Seekers. Wearing a mask at a riot is now a crime. Secret Sqrrl: NSA “spin-off” company releases data mining tool. Pack your bags for possible jail term, judge tells IBM worker over disk row. NSA leaks hint Microsoft may have lied about Skype security. Blog Comment of the Week This week’s best comment goes to Patrick, in response to API Gateways: Access Provisioning.

I am doing some work on FDE (if you are using the Securosis Nexus, I just added a small section on it), and during my research one of our readers sent in some great advice. Here are some suggestions from Guillaume Ross @gepeto42: Things to Check before Deploying FDE Support Ensure the support staff that provides support during business days is able to troubleshoot any type of issue or view any type of logs. If the main development of the product is in a different timezone, ensure this will have no impact on support. I have witnessed situations where logs were in binary formats that support staff could not read. They had to be sent to developers on a different continent. The back and forth for a simple issue can quickly turn into weeks when you can only send and receive one message per day. If you are planning a massive deployment, ensure the vendor has customers with similar types of deployments using similar methods of authentication. Documentation Look for a vendor who makes documentation available easily. This is no different than for any enterprise software, but due to the nature of encryption and the impact software with storage related drivers can have on your endpoint deployments and support, this is critical. (Rich: Make sure the documentation is up to date and accurate. We had another reader report on a critical feature removed from a product but still in the documentation – which lead to every laptop being encrypted with the same key. Oops.) Local and remote recovery Some solutions offer a local recovery solution that allow the user to resolve forgotten password issues without having to call support to obtain a one time password. Think about what this means for security if it is based on “secret questions/answers”. Test the remote recovery process and ensure support staff have the proper training on recovery. Language If you have to support users in multiple languages and/or multiple language configurations, ensure the solution you are purchasing has a method for detecting what keyboard should be used. It can be frustrating for users and support staff to realize a symbol isn’t in the same place on the default US keyboard and on a Canadian French keyboard. Test this. (Rich: Some tools have on-screen keyboards now to deal with this. Multiple users have reported this as a major problem.) Password complexity and expiration If you sync with an external source such as Active Directory, consider the fact that most solutions offer offline pre-boot authentication only. This means that expired passwords combined with remote access solutions such as webmail, terminal services, etc. could create support issues. Situation: The user goes home. Brings his laptop. From home, on his own computer or tablet, uses an application published in Citrix, which prompts him to change his Active Directory password which expired. The company laptop still has the old password cached. Consider making passwords expire less often if you can afford it, and consider trading complexity for length as it can help avoid issues between minor keyboard mapping differences. Management Consider the management features offered by each vendor and see how they can be tied to your current endpoint management strategy. Most vendors offer easy ways to configure machines for automatic booting for a certain period or number of boots to help with patch management, but is that enough for you to perform an OS refresh? Does the vendor provide all the information you need to build images with the proper drivers in them to refresh over an OS that has FDE enabled? If you never perform OS refreshes and provide users with new computers that have the new OS, this could be a lesser concern. Otherwise, ask your vendor how you will upgrade encrypted workstations to the next big release of the OS. Authentication There are countless ways to deal with FDE authentication. It is very possible that multiple solutions need to be used in order to meet the security requirements of different types of workstations. TPM: Some vendors support TPMs combined with a second factor (PIN or password) to store keys and some do not. Determine what your strategy will be for authentication. If you decide that you want to use TPM, be aware that the same computer, sold in different parts of the world, could have a different configuration when it comes to cryptographic components. Some computers sold in China would not have the TPM. Apple computers do not include a TPM any more, so a hybrid solution might be required if you require cross-platform support. USB Storage Key: A USB storage key is another method of storing the key separately from the hard drive. Users will leave these USB storage keys in their laptop bags. Ensure your second factor is secure enough. Assume USB storage will be easier to copy than a TPM or a smart card. Password sync or just a password: A solution to avoid having users carry a USB stick or a smart card, and in the case of password sync, two different sets of credentials to get up and running. However, it involves synchronization as well as keyboard mapping issues. If using sync, it also means a simple phishing attack on a user’s domain account could lead to a stolen laptop being booted. Smart cards: More computers now include smart card readers than ever before. As with USB and TPM, this is a neat way of keeping the keys separate from the hard drive. Ensure you have a second factor such as a PIN in case someone loses the whole bundle together. Automatic booting: Most FDE solutions allow automatic booting for patch management purposes. While using it is often necessary, turning it on permanently would mean that everything needed to boot the computer is just one press of the power button away. Miscellaneous bits Depending on your environment, FDE on desktops can have value. However, do not rush to deploy it on workstations used by multiple users (meeting rooms, training, workstations used by multiple