Securosis

Menu

Research

Friday Summary: March 29, 2013

Adrian Lane March 29, 2013 1 Comment

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

Share:
Read Post

1 in 6 Amazon Web Services Users Can’t Read

Rich March 29, 2013 2 Comments

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:

Share:
Read Post
dinosaur-sidebar

Research

view all

Sign Up for Our Newsletter

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

“Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.”

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.