One of the more pernicious problems in information security is allowing someone to perform something they are authorized to do, but catching when they do it in a potentially harmful way. For example, in most business environments it’s important to allow users broad access to sensitive information, but this exposes us to all sorts of data loss/leakage scenarios. We want to know when a sales executive crosses the line from accessing customer information as part of…
As we continue with “Network Security in the Age of Any Computing”, we have already hit the risks and the need for segmentation to restrict access to sensitive data. Now we focus on technologies that can help restrict access – which tend to be NAC, firewalls, and other network layer controls (such as VLANs and physical segmentation). Each technology has pros and cons. There are no ‘right’ answers – just a set of compromises that must be made b weighing the various available technology options.
In the first post of this series, we talked about the risks inherent to this concept of any computing , where those crazy users want to get at critical data at any time, from anywhere, on any device. And we all know it’s not pretty. Sure, there are things we can do at the device layer to protect the and ensure a proper configurations. But in this series we will focus on how to architect and secure the network to protect critical data. The first aspect of that is restricting access to key…
There’s nothing like a late-night phone call saying, “I think your email has been hacked,” to drop a security professional over the edge. My wife called me during the RSA Conference to tell me this, because some emails she got from me were duplicates that refused to be deleted. Weirdness like that always makes me question my security, and when I found the WiFi still enabled on my phone, I had my yearly conference ‘Oh $#(!’ moment early.
The Friday summary is our chance to talk about whatever, and this week I am going to do just that. This week’s introduction has nothing to do with security, so skip it if you are offended by such things.
I think anyone who writes for a living sometimes neglects to provide the proper context before launching into some big thought. I please guilty as charged on some aspects of the Risk Metrics Are Crap FireStarter earlier this week. As I responded to some of the comments, I used the term science project to describe some technologies like GRC, SIEM, and AppSec. Without context, some folks jumped on that. So let me explain a bit of what I mean.
By now you have probably seen that the U.S. Department of Health and Human Services (HHS) fined Cignet healthcare a whopping $4.3M for, and I believe this is a legal term, being total egotistical assholes. (Because “willfull neglect” just doesn’t have a good ring to it).
It’s been a while since I have gotten into a good old-fashioned Twitter fight. Actually the concept behind FireStarter was to throw some controversial thought balloons out there and let the community pick our stuff apart and help find the break points in our research positions. As Jeremiah tweeted yesterday, “whatever the case, mission accomplished. Firestarter!” to my post Risk Metrics Are Crap. It devolved into a bare-knuckled brawl pretty quickly, with some of the vociferous risk metrics…
We are pleased to kick off the next of our research projects, which we call “Network Security in the Age of Any Computing.” It’s about how reducing attack surface, now that those wacky users expect to connect to critical resources from any device, at any time, from anywhere in the world. Thus ‘any’ computing.
How do you secure data in the cloud? The answer is “it depends”. What type of cloud are you talking about – IaaS, PaaS, or SaaS? Public or Private? What services or applications are you running? What data do you want to protect? Following up on the things I learned at RSA, one statement I heard makes sense now. Specifically, a couple weeks ago Chris Hoff surprised me when, talking about data security in the cloud, he tweeted: