A different kind of APT

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:

Read Post

My DHS Beats Your FDA

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:

Read Post

Understanding IAM for Cloud Services: Integration

“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

Read Post

CISO Rule #1: Don’t be a douche…

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:

Read Post

Friday Summary: January 18, 2013

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

Read Post

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.