Research

What happens when you work for a US critical infrastructure company and see strange connections coming into your network from China? Using the real credentials of your top programmer? You crap your pants, that’s what you do. And you figure you have been compromised by the APT and pull the alarms. But what happens when it’s actually something else. Security audit finds dev OUTSOURCED his JOB to China to goof off at work After getting permission to study Bob’s computer habits, Verizon investigators found that he had hired a software consultancy in Shenyang to do his programming work for him, and had FedExed them his two-factor authentication token so they could log into his account. He was paying them a fifth of his six-figure salary to do the work and spent the rest of his time on other activities. In retrospect, this is hilarious. Unless it was your firm. The guy paid a group in China 20% of his salary to do all his work, while he spent all day surfing the web and watching a bunch of cat videos. Evidently no one thought to look at the logs from the outbound web filter, which likely would have identified this issue much sooner. Though it makes you wonder how much of this kind of arbitrage is going on, doesn’t it? Share:

As someone who has been part of the medical field my entire life (family business before I became a paramedic) the intersection between medicine and technology is of high personal interest. I still remember the time I got in trouble at work for hacking my boss’s password so we could get into the reporting application he accidentally locked everyone out of. Medical IT is, for the most part, the biggest fracking disaster you can imagine. The software is insanely complex and generally terribly written. The user interfaces are convoluted and exactly wrong for the kind of non-technical users they are built for. More often than not there is a massive disconnect between engineers, IT admins, and clinical users. And security? Frequently it’s the thought you have after an afterthought, when you get around to it, on the fifth Wednesday of the second month of the… you get the idea. Hospital IT tends to rely extremely heavily on vendors who use remote access. Inside, the networks are as soft as you can imagine. I’m not saying this to be insulting, and there are most definitely exceptions at some of the more profitable institutions, but most hospitals barely slide by financially, are SMBs, and lack the resources to really invest in a good, structured IT program. Adding fuel to the fire is a vendor community and regulatory body (the FDA) that make the SCADA folks look positively prescient. So it is no surprise that DHS finds themselves stepping in over the FDA to pressure vendors to patch vulnerable systems. After initial bids to contact Philips failed, researchers Rios and colleague Terry McCorkle sought assistance from the DHS, the FDA and the country’s Industrial Control Systems Cyber Emergency Response Team (ICS CERT). Two days later, DHS control system director Marty Edwards told the researchers the agency would from then on handle all information security vulnerabilities found in medical devices and software. The announcement comes month after the US Government Accountability Office said in a report (pdf) that action was required to address medical device flaws, adding that the FDA did not consider such security risks “a realistic possibility until recently”. We’ll see where this goes as the agencies battle it out. But I think this is the start of a long road – I don’t see the funds needed to really address this problem getting freed up any time soon. Share:

“The Cloud” is a term so overused and often misapplied that it has become meaningless without context. This series will discuss identity and access management as it pertains to the three major cloud service models (Infrastructure, Platform, and Software). Each of these models (SaaS, PaaS, and IaaS) presents its own unique challenge for IAM, because each model promotes different approaches and each vendor offers their own unique flavor. The cloud service model effectively acts as a set of constraints which the IAM architect must factor into their architecture. With the SaaS model most enterprises look to federated identity, meaning the enterprise uses federation capabilities to gate access to cloud applications, keeping control over provisioning accounts internal. This approach is both simpler and offers better security policy control than the primary alternative, of replicating accounts into the SaaS provider – copying big chunks of user directories into the cloud. A middle road has emerged where account management is available via a Identity as a Service cloud provider; we will discuss this later in this series. For IaaS, Identity Federation is an option as well, but the need is not as great because you manage everything above the Infrastructure level. Infrastructure providers have some built in capabilities for identity management, but since you control most of the infrastructure, extending your current capabilities into the cloud is a more natural progression. IaaS vendors like Amazon’s AWS have offered limited support for federation over the years, but the quality and depth of their functionality demonstrates that the service providers largely expect customers to handle this. PaaS, as usual, is somewhere in between. Most PaaS service providers offer more robust capabilities, so federation is a first-class choice in most major platforms today. Cloud Identity Deployment Models IAM deployments for the cloud generally use some combination of the following approaches: * Store Accounts in the Cloud: This is exactly what it sounds like: copy your existing accounts into the cloud environment. You effectively replicate or synchronize enterprise user accounts into the cloud provider’s environment. It is conceptually very simple, and as most IT departments are already familiar with directory services, it’s the easiest way to get started in the cloud. It is also a model that creates security problems when you replicate – and potentially expose – sensitive information including keys, passwords, and other access control data. Remember, “The Cloud” is naturally a multi-tenant environment, shared by other customers and administrators not on your staff. Role changes, as well as account removal or disabling, can lag unacceptably before the internal change is effective at the cloud provider. * Federation: The next option is federation, where user identities are managed locally but identity assertions can be validated through tokens presented to the cloud service interface. The enterprise retains local control and management, typically via Active Directory. This removes the issue of secret data (such as passwords) being stored in the cloud. Federation lets the enterprise leverage existing IDM processes, possibly across multiple systems, which simplifies management and provisioning. * IDMaaS: Identity Management as a Service is an emerging architecture to watch. This is effectively a hybrid of the first two approaches. A separate cloud is run for identity management, usually managed by a different cloud service provider, who links directly to internal on-premise systems for policy decision support. One of the major advantages of this approach is that the IDMaaS provider then links you to various cloud services, handling all their technical idiosyncrasies behind the scenes. The IDMaaS provider effectively glues everything together, providing identity federation and authorization support. IAM Service Delivery Most cloud deployments today mainly work toward leveraging federated identity, but this is where the commonality stops. The way identity is used, and the types of IAM services available, cover a wide range of possibilities. Authentication: A deceptively simple concept, which is devilishly hard in practice. As IT managers and programmers we understand in-house authentication – but what about cloud apps, middleware, and proxies? What about privileged users? Where and how is the session controlled? And how are authentication events audited? Authentication is one area most enterprises think they have nailed, but the edges and external interfaces add complexity and raise questions, which are not yet fully addressed. SSO: Single sign-on is table stakes for any cloud provider, but the way it is delivered varies between providers and service models. SSO is a subset of federated identity, and provides the seamless integration users demand. Enterprises should seek cloud providers with open standards based SSO to reduce complex and costly integration work. Standards: First, the good news: there are many identity standards to choose from, and each excels at one aspect of identity propagation. The bad news is there are many identity standards to choose among. Choose wisely – cloud IAM architecture should be standards-based, but the standards should not drive the cloud IAM architecture. Federation: Federation of identity is another sina qua non for SaaS, and a basic capability of most cloud service providers. Key success factors include integration for the federation servers to cloud consumer and cloud provider. Authorization: Identity defines “who is who”, and authorization then defines what those users can do. Traditionally users are assigned roles which define what they can do and access. This makes administration easy, as a single change can update many users with the same role. But roles are not good enough any more; apps need attributes – granular characteristics – provided by an authoritative source. The question is: where are they? Cloud side, enterprise side, or both? Policy-based authorization via XACML is steadily growing trend. Today XACML is more likely to factor into PaaS and IaaS deployments, but it is likely to be the de facto authorization standard in the future. Provisioning: Account and policy lifecycle management – including user account creation, propagation, and maintenance – is primarily an enterprise function. Cloud apps are just another endpoint for the provisioning system to speak to. SCIM is a proposed standard for provisioning, but some people use SAML beyond

Let’s take a look at Adam Shostack’s recent post, “The Phoenix Project may be uncomfortable”. First of all, I haven’t gotten a chance to read Gene Kim’s new book “The Phoenix Project,” but they were kind enough to send me an electronic copy and I will get to it soon. I love the idea of teaching important lessons via a fictional story, even for technology stuff. As much as I like technical books, I don’t read them. I consult them when I have a technical question. But I read stories, and learn by osmosis when plowing through a story I enjoy. In fact I wrote one a while ago using a similar tactic. Now onto one of the characters in the book, the CISO of the fictional company in Gene’s book. So let’s talk frankly about John. John is a shrill jerk who thinks it’s a good idea to hold up business because he sees risk. He thinks of his job as risk prevention and compliance, and damn the cost to the business. If this isn’t the stereotypical security person, I don’t know what is. Of course, there is a reason for that. It seems this whole good guy/bad guy thing is taken too far by too many senior security folks. They get drunk on the power, abuse it, make a mistake, and sooner rather than later are looking for their next gig. Understanding where security fits in a business proposition gives me not only understanding but even sympathy for business leaders who listen to someone claim that if only the CSO reported to the CEO, they’d have a voice. That’s backwards. If the CSO has an understanding of the business, they’ll have a voice, and won’t need to report to the CEO. Also, the CEO is not the person with cycles to mentor a CSO to that understanding. Here Adam hits the nail on the head. Playing in the C-suite is all about business, not technology. If you don’t understand your business, you can’t do the CISO job. It’s as simple as that. The Pragmatic CSO is all about understanding that game, also discussed in this recent SC Mag interview. But first and foremost, to be successful as a CISO you need to be a team player. And you need to understand who your customers are. Share:

I will not write about Manti Te’o. I will not write about Manti Te’o. I will not write about Manti… ah hell, who am I kidding. Wednesday afternoon I was about to head out to meet a buddy for happy hour when he texted that he would be late because of getting caught up in the story (which had just broken). That was cool – I was in the middle of the same article. (If you don’t know what I’m talking about, this should get you up to speed. I admit I’m not the biggest pro sports guy in the world. I enjoy sports, especially football, and played in high school, but years of living in Colorado and spending my winter weekends hunting for fresh powder broke the habit. Living in Phoenix now, I have tried to get back into it, but even if I can snag a TV from my young kids to watch a game, the odds are very high that they will hunt me down to play with them. Seriously, I can’t even take a morning constitutional in peace anymore. Back to Te’o. It is barely conceivable to me that he wasn’t somehow in on it. If this was a catfish, it is one of the best in history (and Te’o should be sent back to community college for remedial reality training). Plus, his family also had to be in on it for their statements to make sense. And let’s not forget the lazy reporters who clearly made s–t up. No, Occam’s Razor likely applies, and Te’o had better sprint to Oprah’s couch before it cools down from Lance. That’s right, it’s liar’s week in the sports world. The buddy I met for happy hour works part time as a sportswriter, and our conversation naturally shifted from Te’o to Lance because I’m big into cycling. As the Lance saga continues I can’t but help be perplexed at the quintuple standard applied to different sports. A lot of people like to call cycling the dirtiest sport out there, but these days it has the strictest performance enhancing drug controls of any professional sport. Not that there still isn’t cheating – it is rampant. When I was out for the Tour last summer the rumor was that the only teams racing solidly clean were Garmin-Sharp-Barracuda (my hosts) and Sky. There were a lot of other clean riders, but more as individuals rather than being on a clean team that managed their own testing to keep things that way. And guess what? A rider from a clean team won the Tour despite battling the dopers. This was possible because the program limits the degree to which people can cheat. Unlike back in Lance’s day, the bio-passport system basically puts a hard limit on how much a rider can enhance without triggering alarm bells. Now go watch some football this weekend. If you think a 300+ pound lineman can legitimately runs a sub-5.0 40, I have a really cute girl on Facebook you should meet. Cycling gets a lot of guff because the riders get caught more, and for some reason people want clean riders. Maybe because, unlike football, a weekend cyclist can directly compare their stats to a pro. Talking with my sportswriter friend, he mentioned they have published articles on potential PEDs in football and no one cares. This despite the fact the increased player size and speed directly correlate to worse injuries and the current problems with traumatic brain injuries. We want our gladiators and we want them big. Sports is entertainment and Sports Center is no different than People Magazine in the end. We want our scandals, heroes, and blood sacrifices, no matter the costs. Just like our… —–, but I won’t go there. Crud. I meant this intro to end with humor. A linebacker, a cyclist, and Oprah walk into a bar… … never mind. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Mike quoted by Reuters on Cisco’s network security competitiveness. Mike quoted in the Merc about Cisco’s network security (missed) opportunity. Adrian’s Dark Reading Post on DB Threats and Countermeasures. Rich’s excellent TidBITS post on Apple’s Security Efforts in 2012. Adrian’s Dark Reading post on Big Data Security Recommendations. Favorite Securosis Posts Adrian Lane: Emotional Whiplash. Mike nailed it. And I only saw the first and fourth quarters! Mike Rothman: Does Big Data Advance Security Analytics? Adrian wins buzzword bingo this week. But the post is important because both Big Data and Security Analytics will be front and center in a lot of security marketing this year. David Mortman: Don’t be a douche… So much for family friendly, eh, Mike? Rich: A different kind of APT. Mike totally stole this one from me. Other Securosis Posts The Fifth Annual Securosis Disaster Recovery Breakfast. My DHS Beats Your FDA. Understanding IAM for Cloud Services: Integration. Time to Play Nice with SCADA Kids. Beware of Self-Proclaimed Experts. Mobile Identity–WTF? Help Me Pick My Next Paper Topic. Bolting on Security – at Scale. Let’s Get Physical – Road Rules Edition. Happy Out of Cycle IE Patch Monday. You Can’t Handle the Truth. Favorite Outside Posts Adrian Lane: Five Mitzvahs of Cloud Computing. Leverage what you’ve got, point 4, is dead-on! Mike Rothman: Steak Drop. Physics FTW. If you ever asked yourself “From what height would you need to drop a steak for it to be cooked when it hit the ground?,” then you need to read this xkcd What-if? post. I wonder if the answer changes if you use a veggie burger? James Arlen: Great stuff in here: NERC CIP V5 is Coming. Places emphasis on the automation of data collection to enable compliant operations. More automation is useful – but much like with banking, you need to be able to do it by hand before you get infatuated with a system. David Mortman: Notes on distributed systems for young bloods. Rich: The Verge on Vegas casinos battling cheating. I’m fascinated by casino security. Research