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.
Posted at Tuesday 2nd July 2013 2:20 pm
(0) Comments •
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.
Posted at Wednesday 26th June 2013 11:05 am
(1) Comments •
I missed this when the update went out last night, but Gregg Keizer at Infoworld caught it:
“Starting with OS X 10.8.4, Java Web Start applications downloaded from the Internet need to be signed with a Developer ID certificate,” Apple said. “Gatekeeper will check downloaded Java Web Start applications for a signature and block such applications from launching if they are not properly signed.”
This was a known hole – great to see it plugged.
Posted at Wednesday 5th June 2013 11:22 am
(1) Comments •
From Macworld: iOS app contains potential malware:
The app Simply Find It, a $2 game from Simply Game, seems harmless enough. But if you run Bitdefender Virus Scanner–a free app in the Mac App Store–it will warn you about the presence of a Trojan horse within the app. A reader tipped Macworld off to the presence of the malware, and we confirmed it.
I looked into this for the article, and aside from blowing up my schedule today it was pretty interesting. Bitdefender found a string which calls an iframe pointing to a malicious site in our favorite top-level domain (
.cn). The string was embedded in an MP3 file packaged within the app.
The short version is that despite my best attempts I could not get anything to happen, and even when the MP3 file plays in the (really bad) app it never tries to connect to the malicious URL in question. Maybe it is doing something really sneaky, but probably not.
At this point people better at this than me are probably digging into the file, but my best guess is that a cheap developer snagged a free music file from someplace, and the file contained a limited exploit attempt to trick MP3 players into accessing the payload’s URL when they read the ID3 tag. Maybe it targets an in-browser music player. The app developer included this MP3 file but the app’s player code isn’t vulnerable to the MP3’s, so exploit nothing bad happens.
It’s interesting, and could easily slip by Apple’s vetting if there is no way the URL could trigger. Maybe we will hear more when people perform deeper analysis and report back, but I doubt it.
I suspect the only thing exploited today was my to do list.
Posted at Thursday 2nd May 2013 1:53 pm
(0) Comments •
In today’s news we see yet another zero-day Internet Explorer exploit being used in the wild.
And once again, soon after becoming public, an exploit was added to Metasploit. Well, sort of. While the in-the-wild attack only works against Windows XP, the Metasploit version works against Windows 7 and Vista. (Note that IE 10 isn’t affected).
You can read the article linked above for the details, but this gets to something I have been recommending privately for a while: support 2 browsers, even if one is only for emergencies.
First of all, ideally you’ll be on a modern operating system. I’m not one to blame the victim, but allowing XP is a real problem – which I know many of you fight every day. Second, this advice doesn’t help with all browser-based attacks, especially Java. But you can configure it in a way that helps.
- Choose a secondary browser that is allowed for web browsing. Chrome is most secure right now, but make sure you set its privacy defaults to not bleed info out to Google.
- Ideally block Java in the browser. Maybe even Flash, depending on how you feel about the Chrome sandbox.
- If something like this IE flaw hits, notify users to use the secondary browser for outside websites (odds are you need IE for internal web apps programmed by idiots or 19th-century transplants, and so cannot ban it completely).
- If you can, set a network policy that (temporarily) blocks IE from accessing external sites (again, you can make exemptions for partners). Unfortunately I don’t believe many tools support this.
I know this advice isn’t perfect. And there are tools like Invincea and (soon) Bromium that can likely stop this stuff cold in the browser – as well as a few network tools, although history shows signature-based defenses aren’t all that effective here. But if you can pull it off you aren’t stuck waiting for a patch or another workaround. Especially if you go with the “block Java / isolate or block Flash” option. This approach allows you to still only support one browser for your applications, and use a secondary one when needed without users having to violate policy to install it themselves.
Posted at Tuesday 18th September 2012 2:27 pm
(2) Comments •
By David Mortman
Today Verizon released their Supplement to the 2009 Data Breach Investigations Report. As with previous reports, it is extremely well written, densely loaded with data, and an absolute must read. The bulk of the report gives significantly more information on the breakdown of attacks, by both how often attacks occurred, and how many records were lost as a result of each attack.
While the above is fascinating, where things got most interesting was in the appendix, which was all about comparing the Verizon data set from 2004 through 2008 to the DataLossDB archives from 2000-2009. One of the big outstanding questions from past Verizon reports was how biased is the Verizon dataset, and thus how well does it reflect the world at large? While there was some overlap with the DataLossDB, their dataset is significantly larger (2,300+ events). Verizon discovered a fairly high level of correlation between the two data sets. (Page 25, Table 4). This is huge, because it allows us to start extrapolating about the world at large and what attacks might look like to other organizations.
The great thing about having so much data is that we can now start to prioritize how we implement controls and processes. Case in point: Table 5 on page 26. We once again see that the vast vast majority (over 70%!) of incidents are from outsiders. This tells us that’s where protection should be focused first. If you go back to the body of the supplement and start looking at the details, you can start to re-evaluate your current program and re-prioritize appropriately.
Posted at Wednesday 9th December 2009 9:23 am
(1) Comments •
By David Mortman
My Friday post generated some great discussion in the comments. I encourage you to go back and read through them. Rocky in particular wrote an extended comment that should be a blog post in itself which reveals that he and I are, in fact, in violent agreement on the issues. Case in point, his first paragraph:
I think we’re on the same page. As an industry we need to communicate more clearly. It wasn’t my intent to fault any information professionals as much as I’m hoping that we all will push a bit harder for
the right conversations in the future. We can’t just let the business make poor decisions anymore, we need to learn their language and engage them in more meaningful dialogue. We’re yelling in the
wrong language. We just need to put that effort into learning their language and communicating more effectively. How is it that we can read HEX in real time but can’t converse with a MBA at any time?
Read the last sentence again. It is that important. This is something I’ve been fighting for for a long time. It’s not about bits and bytes and until we get that through our heads, the rest just doesn’t matter because no one in command will listen to us.
Rocky closed out his comment with this though:
What would IT security look like if we spent as much time on those thoughts as we do on compliance tools, dashboards and monitoring?
I think it’d be much more business centric and hopefully significantly more respected in the C-suite. What do you think?
Posted at Monday 7th December 2009 12:41 pm
(8) Comments •
By David Mortman
Rocky DeStefano had a great post today on FudSec, Liberate Yourself: Change The Game To Suit Your Needs, which you should read if you haven’t already. It nicely highlights many of the issues going on in the industry today. However, I just can’t agree with all of his assertions. In particular, he had two statements that really bothered me.
Information Security Leadership. We need to start pushing back at all levels here. It’s my opinion that business’s need to care much less about being compliant and more about being fundamentally
secure - or if you prefer having better visibility into real risk. Risk to the mission, risk to the business not the risk to an asset. We continue to create irrelevant measurements - irrelevant because they
are point in time, against a less-than secure model and on a playing field that is skewed towards the success of our adversary.
In a perfect, security and risk oriented world, I would agree with this 100%. The problem is, that from the business perspective, what they have in place is usually sufficient to do what they need to do safely. I’m a big fan of using risk, because it’s the language that the business uses, but this isn’t really a compliance versus security vs risk issue. What needs to be communicated more effectively is what compliance to the letter of the law does and doesn’t get you. Where we have failed as practitioners is in making this distinction and allowing vendor and marketing BS to convince business folks that because they are compliant they are of course secure. I can’t count the number of times I’ve had folks tell me that they thought being compliant with whatever regulation meant they were secure. Why? Because that’s the bill of sale they were sold. And until we can change this basic perception the rest seems irrelevant. Don’t blame the security practitioners; most of the ones I know clearly express the difference between compliance and security, but it often falls on deaf ears.
But what really got my goat was this next section:
As information security professionals how on earth did we let the primary financial driver for security spending be compliance initiatives? We sold our souls because we lacked the knowledge of the
business and how to apply what we do in a meaningful way to the business. We let compliance initiatives that promised “measurable” results have their way because we thought we could tag along for
the ride and implement best possible solutions given the situation. As I see it we are no better off for this and now our teams have either competing agendas or more work to drive us away from protecting
our organizations. Sure we’ve created some “building codes” but do “point in time” snapshots matter anymore when the attacker can mold his approach on a whim?
I don’t know who Rocky has been talking to, but I don’t know a single security practitioner who thinks that compliance was the way to go. What I’ve seen are two general schools of thought. One is to rant and rave that everyone is doing it wrong and that compliance doesn’t equal security, but then engages in the compliance efforts because they have no choice. The other school is to be pragmatic and to accept that compliance is here to stay, and do our best within the existing framework. It’s not like we as an industry ‘let’ compliance happen. Even the small group of folks who have managed to communicate well with the business, be proactive, and build a mature program still have to deal with compliance. As for Rocky’s “buildng codes” and “point in time” snapshots, for a huge segment of the business world, this is a massive step up from what they had before.
But to answer Rocky’s question, the failure here is that we told the business, repeatedly, that if they installed this one silver bullet (firewalls, AV, IDS, and let’s not forget PKI) they’d be secure. And you know what? They believed us, every single time, they shelled out the bucks and we came back for more, like Bullwinkle the Moose “This time for sure!” We told them the sky was going to fall and it didn’t. We FUDed our way around the business, we were arrogant and we were wrong. This wasn’t about selling our souls to compliance. It was about getting our asses handed to us because we were too busy promoting “the right way to do things” and telling the business no rather then trying to enable them to achieve their goals.
Want an example? Show me any reasonable evidence that changing all your users’ passwords every 90 days reduces your risk of being exploited. No wonder they don’t always listen to us.
Posted at Friday 4th December 2009 11:50 am
(39) Comments •
This is an article I’ve been thinking about for a long time. Sure, we security folks seem to love to bash Apple, but I thought it would be interesting to take a more constructive approach.
From the TidBITS article:
With the impending release of the next versions of both Mac OS X and the iPhone operating system, it seems a good time to evaluate how Apple could improve their security program. Rather than focusing on narrow issues of specific vulnerabilities or incidents, or offering mere criticism, I humbly present a few suggestions on how Apple can become a leader in consumer computing security over the long haul.
The short version of the suggestions are:
- Appoint and empower a CSO
- Adopt a secure software development program
- Establish a security response team
- Manage vulnerabilities in included third party software
- Complete the implementation of anti-exploitation technologies
Posted at Wednesday 3rd June 2009 6:05 pm
(0) Comments •
Right when the Macalope was sending along his take on the recent ComputerWorld editorial calling for the FTC to investigate Apple, Macworld asked me to write a more somber take. Here’s an excerpt:
On May 26, Macworld republished a controversial Computerworld article by Ira Winkler suggesting that Apple is “grossly negligent” when it comes to security, and should be investigated by the Federal Trade Commission for false advertising. The author was motivated to write this piece based on Apple’s recent failure to patch a known Java security flaw that was fixed on other platforms nearly six months ago. While the article raises some legitimate issues, it’s filled with hyperbole, inaccurate interpretations, and reaches the wrong conclusions. Here’s what you really need to know about the Java situation, Mac security in general, and the important lesson on how we control Apple’s approach to security.
The real failure of this, and many other, calls for Mac security is that they fail to accurately identify those who are really responsible for Apple’s current security situation. It isn’t security researchers, malicious attackers, or even Apple itself, but Apple’s customers. Apple is an incredibly successful company because it produces products that people purchase. We still buy MacBooks despite the lack of a matte screen, for example. And until we tell Apple that security will affect our buying decisions, there’s little motivation for the company to change direction. Think of it from Apple’s perspective—Macs may be inherently less secure, but they are safer than the competition in the real world, and users aren’t reducing what they spend on Apple because of security problems. There is reasonable coverage of Mac security issues in the mainstream press (Mr. Winkler’s claim to the contrary), but without demonstrable losses it has yet to affect consumer behavior.
Don’t worry- I rip into Apple for their totally irresponsible handling of the Java flaw, but there really isn’t much motivation for Apple to make any major changes to how they handle things, as bad as they often are.
Posted at Tuesday 2nd June 2009 5:20 pm
(3) Comments •
Despite my intensive research into cryonics, I have to accept that someday I will die. Permanently. I don’t know when, where, or how, but someday I will cease to exist. Heck, even if I do manage to freeze myself (did you know one of the biggest cryonincs companies is only 20 minutes from my house?), get resurrected into a cloned 20-year-old version of myself, and eventually upload my consciousness into a supercomputer (so I can play Skynet, since I don’t really like most people) I have to accept that someday Mother Entropy will bitch slap me with the end of the universe.
There are many inevitabilities in life, and it’s often far easier to recognize these end results than the exact path that leads us to them. Denial is often closely tied to the obscurity of these journeys; when you can’t see how to get from point A to point B (or from Alice to Bob, for you security geeks), it’s all too easy to pretend that Bob Can’t Ever Happen. Thus we find ourselves debating the minutiae, since the result is too far off to comprehend.
(Note that I’d like credit for not going deep into an analogy about Bob and Alice inevitably making Charlie after a few too many mojitos).
Security includes no shortage of inevitabilities. Below are just a few that have been circling my brain lately, in no particular order. It’s not a comprehensive list, just a few things that come to mind (and please add your own in the comments). I may not know when they’ll happen, or how, but they will happen:
- Everyone will use some form of NAC on their networks.
- Despite PCI, we will move off credit card numbers to a more secure transaction system. It may not be chip and PIN, but it definitely won’t be magnetic strips.
- Everyone will use some form of DLP, we’ll call it CMP, and it will only include tools with real content analysis.
- Log management and SIEM will converge into single products. Completely.
- UTM will rule the day on the perimeter, and we won’t buy separate boxes for every function anymore.
- Virtualization and information-centric security will totally fuck up network security, especially internally.
- Any critical SCADA network will be pulled off the Internet.
- Database encryption will be performed inside the database with native functionality, with keys managed externally.
- The WAF vs. secure development debate will end as everyone buys/implements both.
- We’ll stop pretending web application and database security are different problems.
- We will encrypt all laptops. It will be built into the hardware.
- Signature AV will die. Mostly.
- Chris Hoff will break the cloud.
Posted at Tuesday 14th April 2009 12:17 pm
(12) Comments •
It was nearly three years ago that I started the Securosis blog. At the time I was working at Gartner, and curious about participating in this whole "social media" thing. Not to sound corny, but I had absolutely no idea what I was getting myself into. Sure, I knew it was called social media, but I didn’t realize there was an actual social component. That by blogging, linking to others, and participating in comments, we are engaging in a massive community dialogue. Yes, since becoming an analyst I’ve had access to all the little nooks of the industry, but there’s just something about a public conversation you can’t get in a closed ecosystem. Don’t get me wrong- I’m not criticizing the big research model- I could never do what I am now without having spent time there, and I think it offers customers tremendous value. But for me personally, as I started blogging, I realized there were new places to explore. At Gartner I learned an incredible amount, had an amazingly good time, and made some great friends. But part of me (probably my massive ego) wanted to engage the community beyond those who paid to talk to me.
Thus, after seven years it was time to move on and Securosis the blog became Securosis, L.L.C.. I didn’t really know what I wanted to do, but figured I’d pick up enough consulting to get by. I didn’t even bother to change my little WordPress blog, other than adding a short company page.
It’s now nearly two years since jumping ship without a paddle, boat, lifejacket, any recognizable swimming skills, or a bathing suit. We’ve grown more than I imagined, had a hell of a lot of fun, posted hundreds of blog entries, authored some major research reports, and practically redefined the term "media whore". But we still had that nearly unreadable white-text-on-black-background blog, and if you wanted to find specific content you had to wade through pages of search results. Needless to say, that’s no way to run a business, which is why we finally bit the bullet, invested some cash, and rebuilt the site from scratch. For months now we’ve been blogging less as we spent all our spare cycles on the new site (and, for me, having a kid). I realize we’ve been going on and on about it, but that’s merely the byproduct of practically crapping our pants because we’re so excited to have it up. We can finally organize our research, help people learn more about security, and not be totally embarrassed by running a corporate site that looked like some idiot pasted it together while bored one weekend. Which it was.
I asked Adrian for some closing thoughts, and I absolutely promise this will be the last of our self-congratulatory, self-promotional BS. The next time you hear from us, we’ll actual put some real content back out there.
Some of you may not know this, but I had been working with Rich for a couple of months before most people noticed. Learning that was unsettling! I was not sure if our writing was close enough that people could not tell, or worse, no one cared. But we soon discovered that the author names for the posts was not always coming up so people assumed it was Rich and not Chris or myself. It was several months later still when I learned that the link to my bio page was broken and was not viewable on most browsers. We were getting periodic questions about what we do here, other than blog on security and write a couple white papers, as lots of regular readers did not know. It never really dawned on Rich or I, two tech geeks at heart, to go look at how we presented ourselves (or in this case, did not present ourselves). When a couple business partners brought it up, it was a Homer Simpson "D’oh" moment of self-realization. Rich and I began discussing the new site October of last year, and as there was a lot of stuff we wanted to provide but could not because WordPress was simply not up to the challenge, we knew we needed a complete overhaul. And we still were getting complaints that most people had trouble reading the white text on black background. Yes, part of me will miss the black background ..It kind of conveyed the entire black hat mind set; breaking stuff in order to teach security. It embodied the feeling that "yeah, it may be ugly, but it’s the truth, so get used to it". Still, I do think the new site is easier to read, and it allows us to better provide information and services. Rich and I are really excited about it! We have tons of content we need to tune & groom before we can put it public into the research library, but it’s coming. And hopefully our writing style will convey to you that this blog is an open forum for wide open discussion of whatever security topic you are interested in. Something on your mind? Bring it!
And now for the week in review:
Webcasts, Podcasts, Outside Writing, and Conferences:
Favorite Securosis Posts:
Favorite Outside Posts:
Blog Comment of the Week:
Yeah … and it was only after I submitted both my credit card details and PIN number that I realised that I’m not even going to the RSA conference.
Posted at Friday 10th April 2009 3:52 pm
(4) Comments •
I was amused today when I logged into my business account bank (Wells Fargo) and they had me set up a new set of security questions. The variety wasn’t bad and the questions were reasonably original. After setting them, I was asked to confirm my contact information.
A few minutes later, I received this email:
Thank you for taking the time to set up your security questions. If we ever need to confirm your identity, your ability to give the correct answers to these questions will help us verify it’s you.
If you did NOT set up security questions recently, please call Wells Fargo Online Customer Service immediately at 1-800-956-4442. Please do not reply to this email.
It went right to the email address I could have updated after setting up the security questions. Anyone else notice the problem?
Now there’s a chance that had I changed the email address on that screen after the security questions, I would have received notification at the old address. As a test, I changed my email a couple of times using the regular interface- but no notifications yet.
UPDATE: Got the email, but at the wrong account (the one I changed to, not from).
Is this an exploitable security flaw? Nope, but it’s amusing for us paranoid/cynical types.
(For the record, they’ve been a great bank for the business, no complaints at all.)
Posted at Tuesday 28th October 2008 7:43 am
(0) Comments •
By Adrian Lane
Should network and application security proceed along separate, independent tracks?
Should software security focus solely on the in-context business issues concerning security, and have network security focus on not allowing the software and infrastructure to be undermined?
This is one of those concepts that has been brewing in the back of my mind for some time how. Different data, different availability, and different contexts provide different value propositions and I am not sure they are effective surrogates for one another. A bunch of Hoff’s posts add fire to this thought, and the whole Kaminsky debate shows the value of competition. We willfully merge network, sever and application security concepts as one and the same, and quite often use one to band-aid the other. It’s not working very well.
If competition makes us stronger, maybe we should just stop cooperating and start pointing the finger of blame at one another. Maybe we need a good turf war to generate security competition between IT & Development groups. The network Hatfields vs. the application McCoys, each working harder to make sure they’re not responsible for the next breach.
Posted at Wednesday 6th August 2008 4:30 am
(3) Comments •
If you can tell, with absolute certainty, that systems are vulnerable to an exploit without needing to test the mechanism, what good is served by releasing weaponized attack code immediately after patches are released, but before most enterprises can patch?
Unless you’re the bad guy, that is.
Posted at Thursday 24th July 2008 1:28 am
(23) Comments •