Research

From NATHER’S LAW OF POLICY MANAGEMENT on the Tufin blog: That last one is of particular interest to me today, as I saw a client recently with a rule base for his firewall that was around 1000 rules long. When looking at his compliance results for policy and risk he was showing me hundreds of rules he wanted to mark as exceptions. I was puzzled – almost two thirds of his rule base consisted of exceptions to the compliance policies they were trying to enforce. Bottom line: if your exceptions are out of hand, it’s time to rethink your compliance plans or realign operations with compliance. It is one thing to lose track of how policy aligns with reality, another to not do anything about it. With any kind of positive security policy (defining what is allowed, rather than looking for what is not), you always need to manage exceptions. Michael Hamelin refers to Wendy’s point that “For every configuration there is an equal and opposite exception.” posited in a Dark Reading column back in October. Wendy is exactly right, and the reality is that firewall operational platforms – which the likes of Tufin, AlgoSec and Firemon provide – are more and more prevalent because firewall policies have become unmanageable. And it will get worse as folks continue migrating to the NGFW with application-centric policies. So it’s time to get on top of your rule bases, before things really get ugly. I will be doing some research on this later in Q1. Share:

In the anger and sorrow following Aaron Swartz’s suicide, Rob Graham makes an excellent point in I conceal my identity the same way Aaron was indicted for According to his indictment, Aaron Swartz was charged with wirefraud for concealing/changing his “true identity”. It sent chills down my back, because I do everything on that list (and more). Why do I do all this? That’s none of your business! I mean, all this has perfectly rational explanations in terms of cybersecurity, privacy, and anti-spam. You can probably guess most of the reasons. But explaining myself defeats the purpose. I shouldn’t have to explain myself to you, to prosecutors, or to a jury. I have a human right to privacy, and guarding that right should not be cause for prosecution. In the course of indulging our job-related paranoia, most of us use one or many of these techniques. In the wrong context, these tactics can be used to show an intent to commit fraud or other such behavior. Even if that isn’t your intent. Remember, the Internet and a lot of these technologies have emerged over the past 10 years. Legislation, case law, and legal precedent lag far behind, so it will be at least several years before legal standards of maintaining Internet privacy can be established. Until then there will be a lot of collateral damage. Like Aaron Swartz. Share:

When Mike wrote his review of Rob Graham’s post on what could define criminality on the Internet, he focused on the anonymization piece. Me? I was struck more by Rob’s “Witchcraft is not a crime” post in a very personal way: The problem with computer geeks is that they are too smart. Boundaries obvious to the average person are invisible to geeks. They will run afoul of the law without being aware of it. … What computer geeks do seems like magic to the average person, to the “jury of your peers”. What’s more, magic is essentially the same as witchcraft. Once you believe someone has magical powers, you start to fear them, and question their good intentions. Thus, no matter how good a geek’s intention, it’ll seem like evil black magic to prosecutors and juries. When I was young, before high school, I committed acts that I believe were criminal even under the laws at the time (mid 1980’s). The most common was phone phreaking – I had a source, and later a technique, for getting MCI codes that allowed me to make free phone calls from a pay phone. I also trafficked in stolen online credentials I gathered from the various bulletin board systems I was on. I even used some of these to log into services illegally. I pirated vast amounts of Commodore 64 software, often cracking some of it myself. I had almost no skills. It was all trial and error. At the time? I didn’t think I was doing anything wrong. To me it seemed no different than the times my dad tried to get free HBO by wrapping aluminum foil around our cable line and moving it around until we saw a blurry picture. I wasn’t “stealing” anything (by my flawed reasoning), just exploring a digital world that few people understood. Even my parents asked for the pay phone calls since there weren’t cell phones, and I could rarely hang onto a quarter to call home for a ride back after wrestling practice. By the end of junior high school I realized this activity was illegal and I was risking my future, so I stopped. I probably still pirated C64 games, and continued to poke at the edges of any system I had access to, but a combination of prescience and puberty moved my spare time more into organized sports and other activities than my pre-script-kiddie script-kiddie endeavors. But even as I got older I know I flirted with the illegal. I downloaded music in the early Napster days (and knew at least one FBI agent who did as well). I probed networks in ways that might now be considered breaking the terms of service. As careful as I was. As ethical and thoughtful as I thought I was, I still technically broke laws. Just like every other good security professional I know. We can’t but help see flaws in the system. Sometimes we probe the edges of those flaws to see where the limits are. By our interpretation this is often totally acceptable, but others do not always see it that way. Personally I have long erred on the side of caution. I don’t take certain actions I think are totally fine if I think someone who could cause problems for me might see them another way. But it is always, ALWAYS a struggle to stay aware of these, often apparently arbitrary, lines when I am anywhere near the edge. Any time actual harm isn’t clear. Share:

It appears that Java is still vulnerable to exploit after the latest patch from Oracle. Disabling Java completely probably isn’t possible for many of you, so I suggest you at least use a good web gateway/network IPS/NGFW that filters for malware, and something cloud or VPN based to protect mobile users. Events like this are why I’m so interested (and have been for a long time) in browser virtualization technologies (Bromium, Invincea, anyone else?). This isn’t going to end any time soon. Share:

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

If you follow the security press, you know many predict that big data will transform information security. RSA recently released a security brief on security analytics with big data that mirrors the press. Depending on your perspective, security analytics with big data may be the concept that we’ll leverage big data clusters for actionable intel in coming years. Or if you talk to SIEM vendors who run on top of NoSQL repositories, the future has been here for 5 years. You may go with “none of the above”. To me it is simply a good idea that has yet to be fully implemented, which is currently just something we talk about in the security echo chamber. But that did not stop me from enjoying the paper. And I don’t say that about most vendor-led research. Most of it makes me angry, to the point where I avoid writing about it to avoid saying really nasty things in public, which should not be printed. But I want to make a couple comments on the assumptions here – specifically, “Big data’s new role in security comes at a time time when organizations confront un-precedented risk arising from two conditions:”, which implies a connection to both security concerns and the need for big data analytics. I think that link is tenuous, and serves their premise poorly. The dissolving perimeter has little or nothing to do with security analytics with big data. The “dissolving perimeter” became a topic for discussion because third-party cloud services, combined with mobile devices, have destroyed the security value of the corporate IT ‘perimeter’. The ‘edge’ of the network now has so many holes that it no longer forms a discernible boundary between inside and outside. We do, however – given the number of servers, services, and mobile computing platforms (all programmed to deliver event data) get a wealth of constantly generated information. Cheap computing resources, coupled with nearly free analytics tools, make storage and processing of this data newly feasible. And do you think we have more sophisticated adversaries? APT is one argument for this idea, but I tend to think we have more determined adversaries. Given the increasing complexity of IT systems, there seems to be plentiful “low-hanging fruit” – accessible security vulnerabilities for attackers to take advantage of. We have evidence that some security measures are really working – Jeremiah Grossman discussed how this is shifting attacker tactics. Many attacks are not so sophisticated, but still hard to detect. I think the link to big data and attackers appears when you couple the complexity of IT environments with the staggering volume of data, and it becomes very difficult to find the proverbial needle in the haystack. The good news is that this is exactly the type of outlier big data can detect – provided it’s programmed to do so. But ultimately I agree with their assertions, albeit for slightly different reasons. I have every confidence that big data holds promise for security intelligence, both because I have witnessed attacker behavior captured in event data just waiting to be pulled out, and because I have also seen miraculous ideas sprout from people just playing around with database queries. In the same way hackers stumble on vulnerabilities while playing with protocols, engineers stumble on interesting data just by asking the same question (query) different ways. The data holds promise. The mining of most data, and all of the work that will be required in writing M-R scripts to locate actionable intelligence, is not yet here. It will take years of dedicated work – and it’s will take script development on different data types for different NoSQL varieties. Finally, I like the helpful graphic differentiating passive vs. active inputs. I also really like Amit Yoran’s commentary; he is dead on target. The need to aggregate, normalize, and correlate in advance can go away when you move to big data repositories. It’s ironic, but you can get better intelligence faster when you do not pre-process the data. It may smell a bit like forecasts and new year’s predictions, but the paper is worth a read. Share: