Research

Huawei not expecting growth in US this year due to national security concerns (The Verge). U.S. to scrutinize IT system purchases with ties to China (PC World): U.S. authorities will vet all IT system purchases made from the Commerce and Justice Departments, NASA, and the National Science Foundation, for possible security risks, according to section 516 of the new law. “Cyber-espionage or sabotage” risks will be taken into account, along with the IT system being “produced, manufactured, or assembled” by companies that are owned, directed or funded by the Chinese government. This is how you fight asymmetric espionage. Expect the consequences to continue until the attacks taper off to an acceptable level (yes, there is an acceptable level). Share:

Threatpost reports that California is considering a law requiring companies to show consumers what data is collected on them. Known as the “Right to Know Act of 2013,” AB 1291 was amended this week to boost its chances of success after being introduced in February by state Assembly member Bonnie Lowenthal. If passed, it would require any business that retains customer data to give a copy of that information, including who it has been shared with, for the past year upon request. It applies to companies that are both on – and offline. The claim is that it doesn’t add data protection requirements, but it does. Here is how: You will need mechanisms to securely share the data with customers. This will likely be the same as what healthcare and financial institutions do today (generally email encryption). You will need better auditing of who data is shared with. Depending on interpretation of the law, you might need better auditing of how it is used internally. Right now this doesn’t seem to be a requirement – I am just paranoid from experience. What to do? For now? Nothing. Remember the Compliance Lifecycle. Laws are proposed, then passed, then responsibility is assigned to an enforcement body, then they interpret the law, then they start enforcement, then we play the compensating controls game, then the courts weigh in, and life goes on. Vendors will likely throw AB 1291 into every presentation deck they can find, but there is plenty of time to see how this will play out. But if this goes through, there will definitely be implications for security practitioners. Share:

Brian Krebs thinks he may have identified the author of the Flashback Mac malware that caused so much trouble last year. Brian is careful with accusations but displays his full investigative reporting chops as he lays out the case: Mavook asks the other member to get him an invitation to Darkode, and Mavook is instructed to come up with a brief bio stating his accomplishments, and to select a nickname to use on the forum if he’s invited. Mavook replies that the Darkode nick should be not be easily tied back to his BlackSEO persona, and suggests the nickname “Macbook.” He also states that he is the “Creator of Flashback botnet for Macs,” and that he specializes in “finding exploits and creating bots.” Brian has started to expose more detailed information from his access to parts of the cybercrime underground, and it’s damn compelling to read. Share:

We (Rich and Gal) were chatting last week about the destructive malware attacks in South Korea. One popular theory is that patch management systems were compromised and used to spread malware to affected targets, which deleted Master Boot Records and started wiping drives (including network connected drives), even on Linux. There was a lot of justfied hubbub over the source of the attacks, but what really interested us is their nature, and the implications for our defenses. Think about it for a moment. For at least the past 10 years our security has skewed towards preventing data breaches. Before that, going back to Code Red and Melissa, our security was oriented toward preventing mass destructive attacks. (Before that it was all Orange Book, all the time, and we won’t go there). Clearly these attacks have different implications. Preventing mass destruction focuses on firewalls (and other networking gear, for segmentation, not that everyone does a great job with it), anti-malware, and patching (yes, we recognize the irony of patch management being the vector). Preventing breaches is about detection, response, encryption, and egress filtering. The South Korean attack? Targeted destruction. And it wasn’t the first. We believe Stratfor had a ton of data destroyed. Stuxnet (yes, Stuxnet) was a fire and forget munition. But, for the most part, even Anonymous limits their destructive activities to DDoS and the occasional opportunistic target. Targeted destruction isn’t a new game but it’s one we haven’t played much. Take Rich’s Data Breach Triangle concept, or Lockheed’s Cyber Kill Chain. You have three components to a successful attack – a way in, a way out, and something to steal. But for targeted destruction all you need is a way in and something to wreck. Technically, if you use some fire and forget malware (single-use or worm), you don’t even need to interact with anything behind the target’s walls. No one was sitting at a Metasploit console on the other side of the Witty Worm. So what can we do? We definitely don’t have all the answers on this one – targeted destructive attacks, especially of the fire and forget variety, are hard as hell to stop. But a few things come to mind. We cannot rely on response after the malware is triggered, so we need better segregation and containment. Note that we are skipping traditional defense advice because at this point we assume something will get past your perimeter blocking. Rich has started using the term “hypersegregation” to reflect the increasingly granular isolation we can perform, even down to the application level in some cases, without material management overhead increasing (read more). As you move more into cloud and disk-based backups, you might want to ensure you still keep some offline backups of the really important stuff. We don’t care whether it’s disk or tape, but at some point the really critical stuff needs to be offline somewhere. Once again, incident response is huge. But in this case you need to emphasize the containment side of response more than investigation. On the upside these attacks are rarely quiet once they trigger. On the downside they can be quite stealthy, even if they ping the outside world for commands. But there is one point in your favor. Targeted destruction as an endgame is relatively self-limiting. There’s a reason it isn’t the dominant attack type, and while we expect to see more of it moving forward but it isn’t about to be something most of us face on a daily basis. Also, because malware is the main mechanism, all our anti-exploitation work will continue to pay off, making these attacks more and more expensive for attackers. Well, assuming you get the hell off Windows XP. Share:

Emergency services providers and others are being hit with telephone-based denial of service attacks. Nasty stuff, powered by IP-based phone systems. This relates to SWATing (what hit Brian Krebs). It has become trivial to use computers to make and spoof phone calls. This is the sort of thing that could lead to new regulations. It is already against the law, but these incidents may lead to rules tightening how companies connect to the phone system. Which probably isn’t great for innovation, and might not work anyway. Share:

Now that we have covered the basics of how IaaS platforms store data, we need to spend a moment reviewing the parts of an encryption system that are relevant for protecting cloud data. Encryption isn’t our only security tool, as we mentioned in our last post, but it is one of the only practical data-specific tools at our disposal in cloud computing. The three components of a data encryption system Cryptographic algorithms and implementation specifics are important at the micro level, but when designing encryption for cloud computing or anything else, the overall structure of the cryptographic system is just as important. There are many resources on which algorithm to select and how to use it, but far less on how to piece together an overall system. When encrypting data in the cloud, knowing how and where to place these pieces is incredibly important, and one of the most common causes of failure. In a multi-tenant environment – even in a private cloud – with almost zero barriers to portability, we need to pay particular attention to where we manage keys. Three major components define the overall structure of an encryption system are: The data: The object or objects to encrypt. It might seem silly to break this out, but the security and complexity of the system are influenced by the nature of the payload, as well as where it is located or collected. The encryption engine: The component that handles the actual encryption (and decryption) operations. The key manager: The component that handles key and passes them to the encryption engine. In a basic encryption system all three components are likely to be located on the same system. As an example take personal full disk encryption (the built-in tools you might use on your home Windows PC or Mac): the encryption key, data, and engine are all stored and used on the same hardware. Lose that hardware and you lose the key and data – and the engine, but that is’t normally relevant. (Neither is the key, usually, because it is protected with another key that is not stored on the system – but if the system is lost while running, with the key is in memory, that becomes a problem). In a traditional application we would more likely break out the components – with the encryption engine in an application server, the data in a database, and key management in an external service or appliance. In cloud computing some interesting limitations force certain architectural models: As of this writing, we cannot typically encrypt boot instances the way we can encrypt the full disk of a server or workstation. So we have fewer options for where to put and how to secure our data. One risk to protect against is a rogue cloud administrator, or anyone with administrative access to the infrastructure, seeing your data. So we have fewer options for where to securely manage keys. Data is much more portable than in traditional infrastructure, thanks to native storage redundancy and data management tools such as snapshots. Encryption engines may run on shared resources with other tenants. So your engine may need special techniques to protect keys in live memory, or you may need to alter your architecture to reduce risk. Automation dramatically impacts your architecture, because you might have 20 instances of a server spin up at the same time, then go away. Provisioning of storage and keys must be as dynamic and elastic as the underlying cloud application itself. Automation also means you may manage many more keys than in a more static, traditional application environment. As you will see in the next sections when we get into details, we will leverage the separation of these components in a few different ways to compensate for many of the different security risks in the cloud. Honestly, the end result is likely to be more secure than what you use in your traditional infrastructure and application architectures. Share:

I almost didn’t write this post since it’s about iOS, and I about defending iOS security too much. Not that I think I’m biased, but I worry about being misinterpreted as an apologetic defender (I’m not – Apple still has security issues they need to work on, but iOS is in really good shape these days). That said, this piece by Erika Morphy over at Forbes is so horribly written, poorly researched, and miscast, that I cannot help myself. It could have been written about other platforms and I would have the same reaction. I know hammering ill-informed press is like tilting at windmills, but every now and then a guy just needs to let loose. The press likes to sensationalize security, and sometimes with good reason. But articles like this juxtapose incorrect information and cherry-picked quotes to scare users needlessly. They are the local news of the Internet, and we shouldn’t give them a pass. This piece is an excellent example of poor writing, and the analysis of why it’s garbage is just as relevant for any sensationalistic piece, whatever the subject, that lands in front of us. First some factual corrections: Kaspersky Labs reports that the first malware to specifically target Google’s Android mobile operating system has been discovered. No. It’s the first targeted attack using Android they’ve seen, not the first to target Android. Big difference. iOS was found to be the most vulnerable in a report by SourceFire. Wrong. Those are historical vulnerabilities, not current vulnerabilities. Big difference. That’s like lumping all Windows vulnerabilities since Windows 1.0 together to say Windows 8 is the most vulnerable platform out there. And vulnerabilities don’t equate to exploits. Raw, historical vulnerability counts are effectively meaningless for evaluating security on any platform. It is the rate of zero-day exploits, not vulnerabilities, that has everyone’s panties in a bunch. These two worlds-smugly complacent Apple users and an iOS apparently riddled with vulnerabilities-will surely collide sooner or later, probably sooner. Do I need to address this? Really? A factually incorrect ad hominem attack? Look at the rise of adware aimed specifically at Macs, which has been rising since the beginning of the year Damn. My Ford Escape was recalled, so I had better assume my Ford Explorer is dangerous. Movie trailer! Media player! I would have thought Mac users to be smarter than that, being one of them myself. Well, I do suppose this helps prove a point, but probably not the one you were trying to make. Share:

Our last nine months of research into identity and access management have yielded quite a few surprises – for me at least. Many of these new perspectives I have shared piecemeal in various blogs, and others not. But it occurred to me today, as we start getting feedback from the dozen or so IAM practitioners we have asked to critique our Cloud IAM research, that some key themes have been lost in the overall complexity of the content. I want to highlight a few points that really hit home with me, and which I think are critical for security professionals in general to understand. BYOD. MDM. MAM. That’s all BS. Mobile security is fundamentally an identity problem. Once you appreciate that a smartphone is essentially a multi-tenant smart card, you start to get a very different idea what mobile security will ultimately look like. How very little IAM and security people – and their respective cultures – overlap. At the Cloud Identity summit last year, the security side was me, Gunnar, and I think one other person. The other side was 400 other IAM folks who had never been to RSA before. This year at the RSA Conference was the first time I saw so many dedicated identity folks. Sure RSA, CA, Oracle, and IBM have had offerings for years, but IAM is not front and center. These camps are going to merge … I smell a Venn diagram coming. Identity is as glamorous as a sidewalk. Security has hackers, stolen bank accounts, ATM skimmers, crypto, scary foreign nationals, Lulz, APT, cyberwar, and stuff that makes it into movies. Identity has … give me a minute … thumbprint scanners? Anyone? Next time security complains about not having a “seat at the management table”, just be thankful you have C-level representation. I’m not aware of a C-level figure or Identity VP in any (consumer) firm. Looking back at directory services models to distribute identity and provide central management … what crap. Any good software architect, even in the mid-90s, should have seen this as a myopic model for services. It’s not that LDAP isn’t a beautifully simplistic design – it’s the inflexible monolithic deployment model. And yet we glued on appendages to get SSO working, until cloud and mobile finally crushed it. We should be thankful for this. Federation with mobile is disruptive. IT folks complain about the blurring of lines between personal and corporate data on smartphones. Now consider provisioning for customers as well as employees. In the same pool. Across web, mobile and in-house systems. Yeah, it’s like that. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Database Security Restart. Adrian’s DR post. Follow The Dumb Security Money. Mike’s DR post. Who has responsibility for cloud security? Mike appears in a NetworkWorld roundtable, and doesn’t say anything (too) stupid. Imagine that! Adrian’s DR paper: Security Implications Of Big Data. Favorite Securosis Posts Adrian Lane: Developers and Buying Decisions. Yeah, it’s my post, spurred by Matt Asay’s piece on how cost structures are changing tech sales. I should have split it into two posts, to fully discuss how Oracle is acting like IBM in the early 90s, and then the influence of developers on product sales. Mike Rothman: Developers and Buying Decisions. Adrian predicts that developers may be more involved in app security buying decisions. What could possibly go wrong with that? Rich: Developers and Buying Decisions. Fail to understand the dynamics and economics around you, and you… er… fail. David Mortman: Defending Cloud Data: IaaS Encryption. Gal Shpantzer: Who’s Responsible for Cloud Security? Other Securosis Posts DDoS Attack Overblown. Estimating Breach Impact. Superior Security Economics. Incite 3/27/2013: Office Space. Server Side JavaScript Injection on MongoDB. How Cloud Computing (Sometimes) Changes Disclosure. Identifying vs. Understanding Your Adversaries. Apple Disables Account Resets in Response to Flaw. Friday Summary: March 22, 2013, Rogue IT Edition. Favorite Outside Posts Rich: What, no Angry Birds? Brian Katz nails it – security gets the blame for poor management decisions. I remember the time I was deploying some healthcare software in a clinic and they asked me to block one employee from playing EverQuest. I politely declined. Gal Shpantzer: Congress Bulls Into China’s Shop David Mortman: Top 3 Proxy Issues That No One Ever Told You. Mike Rothman: You Won’t Believe How Adorable This Kitty Is! Click for More! Security is about to jump the shark. When social engineering becomes Wall Street Journal fodder we are on the precipice of Armageddon. It doesn’t hurt that some of our buddies are mentioned in the article, either… Adrian Lane: Checklist To Prepare Yourself In Advance of a DDoS Attack. A really sweet checklist for DDoS preparedness checklist. Dave Lewis: ICS Vulnerabilities Surface as Monitoring Systems Integrate with Digital Backends. Don’t know if it’s real, but it is funny! Project Quant Posts 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. Top News and Posts Spamhaus DDoS Attacks Evernote: So useful, even malware loves it. Evernote as botnet C and C. Google glasses. Just friggin’ funny! Your WiFi-enabled camera might be spying on you “Browser Crashers” Hit Japanese Users Victim of $440K wire fraud can’t blame bank for loss, judge rules. This is going to be a hot topic for the next several years. FBI Pursuing Real-Time Gmail Spying Powers as “Top Priority” for 2013 Amazing Plaintext Password Blunder Chaos Communication Camps. Or should that be Kamps? “Lucky Thirteen” Attack MI5 undercover spies: People are falsely claiming to be us. This has occurred a few times before. GCHQ attempts to downplay amazing plaintext password blunder Slow Android Phone Patching Prompts Vulnerability Report Lawyer hopeful of success with secure boot complaint Cyberbunker’s Sven Kamphuis says he is victim of conspiracy over Spamhaus attack One in six Amazon S3 storage buckets are ripe for data-plundering That Internet War Apocalypse Is a

Rapid7 reported this week on finding a ton of sensitive information in Amazon S3. They scanned public buckets (Amazon S3 containers) by enumerating names, and concluded that 1 in 6 had sensitive information in them. People cried, “Amazon should do something about this!!” S3 buckets are private by default. You have to make them public. Deliberately. If you leave a bucket public, you eventually get an email like this (I have a public bucket we use for CCSK training): Dear Amazon S3 Customer, We’ve noticed that your Amazon S3 account has a bucket with permissions that allow an anonymous requester to perform READ operations, enumerating the contents of the bucket. Bucket READ access is sometimes referred to as “list” access. Amazon S3 buckets are private by default. These S3 buckets grant anonymous list access: REDACTED Periodically we send security notifications to all of our customers with buckets allowing anonymous list access. We typically recommend against anonymous list access. We know there are good reasons why you may choose to allow anonymous list access. This can simplify development against S3. However, some tools and scripts have emerged which scan services like Amazon S3 and enumerate objects in publicly listable buckets. With anonymous list access enabled, anyone (including users of these tools) may obtain a complete list of your bucket content. As a result of calls against your bucket, you may see unintended charges in your account. We’ve included specific steps to remove anonymous list access as well as further information about bucket access considerations. Use the following steps to immediately remove anonymous access to your bucket. Go to the Amazon S3 console at https://console.aws.amazon.com/s3/home. Right-click on the bucket and click Properties. In the Properties pane, click the Permissions tab. The tab shows a list of grants, one row per grant, in the bucket ACL. Each row identifies the grantee and the permissions granted. Select the row that grants permission to everyone. “Everyone” refers to the Amazon S3 All User group. Uncheck all the permissions granted to everyone (or click x to delete the row). This removes all permissions granted to public. Click Save to save the ACL. Learn more about protecting your bucket by reading the AWS article on Amazon S3 Bucket Public Access Considerations at http://aws.amazon.com/articles/5050. This article includes alternative options if you need methods for unauthenticated end users to read and write content, as well as detailed information on configuring bucket access for website hosting if you are hosting your site on Amazon S3. It also describes how you can use Bucket Policies if you would like to specify more granular access control on your bucket. Bucket Policies enable you to add or deny permissions across all or a subset of objects within a bucket. You can use wildcarding to define sets of objects within a bucket against which policy is applied, more specifically control the allowed operations, and even control access based on request properties. For further information on managing permissions on Amazon S3, please visit the Amazon S3 Developer Guide at http://docs.amazonwebservices.com/AmazonS3/latest/dev/Welcome.html for topics on Using ACLs and Using Bucket Policies. Finally, we encourage you to monitor use of your buckets by setting up Server Access Logging. This is described in our Developer Guide under Setting Up Server Access Logging. Sincerely, The Amazon S3 Team My scientific conclusion? 1 in 6 Amazon S3 users can’t read, or don’t care. Seriously, what do you want Amazon to do? Drive to your house if you mess up and then ignore their warnings? Share:

Sam Biddle at Gizmodo says: This guy, Prince said, could back up CloudFlare’s claims. This really was Web Dresden, or something. After an inquiry, I was ready to face vindication. Instead, I received this note from a spokesperson for NTT, one of the backbone operators of the Internet: “Hey Sam, nice to hear from you. I’m afraid that we don’t have anything we can share that substantiates global effects. I’m sure you read the same 300gbps figure that I did, and while that’s a massive amount of bandwidth to a single enterprise or service provider, data on global capacities from sources like TeleGeography show lit capacities in the tbps range in most all regions of the world. I side with you questioning if it shook the global internet. Chris” Bad for SpamHaus, but unnoticeable to everyone else. Share: