Posts by author:

Branden Williams

Herding Cats: No Bubble People (February 2012)

by Branden Williams on February 3, 2012

in SBN

kitten, by Clevergrrl

Have you checked out ISSA Connect yet? The next issue is up there with my column, No Bubble People.

We must assume malware will end up in our network. Unless we treat our users like the Boy in the Bubble, they will click things and infect themselves—many times without even realizing it. This month’s column discusses the war we face understanding that we cannot fight or even win every battle.

If you are a member, log into ISSA Connect and join the discussion! Interact with great professionals globally as well as the authors that you enjoy reading every month. If you are not a member, sign up today!

Possibly Related Posts:


Share

{ Comments on this entry are closed }

January 2012 Roundup

by Branden Williams on February 2, 2012

in SBN

Stay Classy, San Diego!

Stay Classy, San Diego!

What was popular in January? We’re already one month down in this new year and most of us have our sites set on RSA Conference in three weeks. Let’s talk infosec!

Here are the five most popular posts from last month:

  1. Myth Busting with Ben Tomhave and Corporate Responsibility with Ben Tomhave took the top two spots this month. Ben Tomhave and I got into a fun discussion over Twitter that ended up going in two directions. First, can merchants self-assess, negating the need for a QSA-lead merchant assessment?
  2. Intelligence Driven Security. The latest Security for Business Innovation Council report is out, and one key indicator is that we have tuned our systems to support compliance, not security. Read this post to learn why this is a fatal flaw in your thinking.
  3. Where is your Chaos Monkey? This one is in the top five for the fourth month in a row! I absolutely love that this concept is being discussed as a reality in Information Security circles. Is your company’s culture prepared to deal with incidents? Netflix has one, where’s yours?
  4. We Must Hunt. In line with some of the other themes this month, I discuss the need for hunters in your information security group. If you organize your department around the “sit around and wait for an incident” plan, you end up waiting for bad stuff to happen and try to catch it before it gets worse. Actively looking for threats inside your network will shorten your kill-chain exposure.

Thanks for stopping by!

Possibly Related Posts:


Share

{ Comments on this entry are closed }

Hardware Security, the New Frontier?

by Branden Williams on February 1, 2012

in SBN

RSA Conference is right around the corner, and I’m excited to actually be able to see some talks this year. I’m on a panel with Dave Navetta and Serge Jorgensen on Tuesday covering the Dark Side of a Payment Card Breach (LAW-107, Room 131, 2:40pm). I am sure if you are there, we will bump into each other somewhere along the way!

Soft Landing, by moonjazz

One of the topics that I want to explore with other security folks while I am there is a shift to hardware-focused exploits whereby you bypass software and focus on firmware to control machines. It’s not a new concept and has been seen in both theoretical and actual attacks on systems. But as software vulnerabilities are closed, the bad guys have to come up with new ways to get into systems. It doesn’t have to be super creative or advanced to be effective. It could be as simple as tricking a device to “update” its firmware with one you have crafted, thus giving you full control over the device.

This becomes particularly critical when you look at devices that have simple but important functions and are rarely touched by technicians. Things that are out in the field like smart meters, pump controllers, payment terminals, and traffic lights. Some people might choose highly technical and specialized attacks that include drilling tiny holes and snaking wires into the hardware, but if you can figure out how to replace its firmware with yours you can effectively scale the attack remotely.

The outcomes vary greatly from nuisance to data theft to cyber-terrorism. Bricking my DVD player is a nuisance, shutting down a town’s water supply is an entirely different matter. If I can compromise a peripheral hardware device, what does that get me? Am I just messing around with a display device? Or am I in the system at a base layer that invalidates software security controls?

Possibly Related Posts:


Share

{ Comments on this entry are closed }

Intelligence-Driven Security

by Branden Williams on January 26, 2012

in SBN

RSA released the ninth installment of the Security for Business Innovation Council report last week, and through a series of blog posts on Speaking on Security, we’re going to analyze the various areas highlighted in the findings. Today I’m going to explore the concept of Intelligence-Driven Security. In our world, intelligence-driven means that information coming in from all of our available sources will influence our actions—some of which will become automated over time.

The report makes a pretty sad claim about the global state of information security, one that has been explored here in the past and largely derivative of the old subject of my blog. Security programs tend to be compliance driven, or even worse, simply optimized for compliance. We focus on keeping the auditors off of our back instead of really thinking about the visibility we need in our environment to discover and combat cyber-threats.

Troop Inspection (Explored), by pasukaru76

First off, how sad is that?

I don’t think I’ve met a security professional who said that he was the happiest of the happy clams because his daily job was defending the network against PCI assessors and other auditors. Those guys don’t go to Shmoo, or BlackHat, or Defcon, or even BSides. They wouldn’t know what an advanced attack looked like until someone gave them theories on how their network was breached. Why just theories? Because compliance-led security will ignore key elements of intelligence that can help you spot and stop an attack.

Now, not all security programs are compliance-led; some have shifted to an incident-led approach. I imagine these folks can’t remember what the place looked like without giant fires blazing through the campus. They choose to wear shorts and crank down the A/C instead of finding the pyromaniac in their midst. Constant reaction to events creates unplanned work which derails our ability to actually make real progress in our IT-driven business.

The challenge with intelligence-led security lies in our ability to reliably and consistently collect the right intelligence from the right sources, manage and correlate that data, learn about what the bad guys are doing and take action all while using a risk-based approach to dictate how you act upon and share this information. It isn’t easy, and as an industry we’re behind. But don’t despair! The SBIC’s ninth report outlines not only many other characteristics and examples of intelligence driven security, but it also gives you an actionable, six-step roadmap to convert your team and function to be intelligence-led. There are some fantastic charts and work product that can be immediately actionable by your teams to help you shift your focus to the things that matter. Go check it out and start your journey!

Possibly Related Posts:


Share

{ Comments on this entry are closed }

Corporate Responsibility with Ben Tomhave

by Branden Williams on January 19, 2012

in SBN

This is part two in a conversation that I had with Ben Tomhave (@falconsview) last week over Twitter. What started out as a quick question about busting PCI myths turned into corporate responsibility. If you haven’t seen this article about a company who is facing massive penalties, give it a read. It will help set up my position on corporate responsibility for promoting longevity. My position:

Companies must make security and compliance a core part of their competency if they choose to operate in a manner that puts them in the cross-hairs of regulation.

During the conversation, we moved to overall organizational competency around areas that arguably sit on the fringe of their core business. Restaurants that make pizza should do that well, and not focus on other things as much. While on the surface I agree with this, I also think that being in business is inherently risky, and business owners should have good knowledge (or hire people that do) about the risks that apply to them.

Take the business to consumer environment for example. If you want to get money from a customer, you have a few options to do so. If you choose to accept payment cards, you need to understand how that acceptance affects your risk model. Is it overly-complex? Definitely. Is ignorance an excuse? Never. This was something that used to drive me nuts as an assessor. The role of a QSA is to see how your company stacks up against PCI DSS, not be a liability transfer in case of a breach. If your organization faces compliance with PCI DSS, HIPAA, Health Codes, or local town ordinances, it must understand what those things mean to the business and build internal competency around it.

On to the discussion (again, slightly edited):

Ben: That statement also ignores that, while PCI may be your full-time job, it’s certainly not an organization’s (in general).

Me: If it’s that impactful to an organization’s bottom line, they should have the competency to handle it.

Ben: I think that’s a backwards and incorrect attitude. Audit/Compliance/Security is *not* their business. Business is. Audit/compliance/security/etc are merely attributes or emerging properties of their overall business…

Me: I think any company that doesn’t fully understand their business is backwards. PCI is a reality if they choose to accept CCs. Businesses choose to do things a certain way which causes audit/compliance/security.

Ben: While all this focus on audit/compliance/security may be good for you, it may not be so good for businesses. Focusing on the wrong things detracts from the right things (building a successful business that is resilient/survives)

Me: I’m not saying that audit is good because I might make money at it, I’m saying businesses choose to take risk, therefore they must live with the consequences, whatever they may be. Otherwise, divest/change.

Cracked Wall Foundation, by PJFurlong06

Part of building a resilient business that will survive is good corporate risk management. Both Ben & I agree on this point. Executives need to know the level of risk they carry, and be able to make decisions on future actions based on how that affects their risk. For example, an over-leveraged company probably wouldn’t choose to take on more debt to expand (solvency risk), and a company relying on credit cards for customer revenue should know how banking rules affect their business (compliance risk).

Many merchants that are compromised usually are told about PCI DSS, but they never invest enough time and energy to know if what they are doing increases or decreases their compliance risk. Not only are they notified by their banks (albeit not uniformly or consistently), but most of these folks participate in an industry consortium that no doubt bring up the PCI topic often to their membership. Yet when merchants are breached, they blame everyone but themselves.

The best businesses are managed at a detail level. I’m not talking about micro-management by an executive—I’m talking about using detailed information to empower employees with competency and skill to drive the business forward, or by outsourcing things to third parties that are qualified experts and will accept the liability on the business’s behalf. Visibility into the risk you carry at any given time isn’t required to make a decision about what comes next, but if you want to know how your decision will affect the future you need to have a clear picture of what today looks like. You don’t HAVE to know anything about PCI DSS, but if you actually read (decoded is probably more accurate) the contracts you signed when you got your merchant account, you would know that you have to comply with certain security standards. You obviously can choose to ignore these standards, but you look ridiculous when you point the finger at someone else after a breach.

Of course, it’s getting harder for business owners to learn about their risks thanks to complex software packages being offered as a service. Business owners are attracted by the glitz and glamor of a fancy piece of software, yet they don’t really understand how to use it or understand the liabilities associated with the information stored—that is, until a breach happens.

Take a left turn, by Netream

Citizens of a civilized society are expected to follow the rules of that society. Ignorance is never a defense. If you choose to operate a vehicle on the road, you are expected to know all of the rules for performing that action and risk fines if you operate outside those rules. Do most of us push the speed limits when we drive? Yep, but we also accept that those flashing blue and red lights behind us mean we’re going to pay for breaking the rule. Claiming you didn’t know that certain information needed to be protected is like telling a cop that you didn’t know the speed limit, therefore you should be excused from responsibility. It doesn’t have to be something like a speed limit either. What about passing a school bus when its red lights are flashing? That’s illegal around here, and you deserve a ticket if you do this.

Ultimately, it comes down to choice. We all choose how involved we get in certain parts of our business, but that means we have to be responsible when things get away from us in areas where we stayed an inch deep. There is always an alternative. For example: how many cash-only businesses with on-premises ATMs have you seen pop up over the last few years? I’m certainly seeing a few more. Talk about a fast way to solve a PCI DSS problem and lower your compliance risk!

Curious on what Ben has to say? Check out his piece here!

Possibly Related Posts:


Share

{ Comments on this entry are closed }

Links for 2012-01-17

by Branden Williams on January 17, 2012

in SBN

Links for 2012-01-17:

Possibly Related Posts:


Share

{ Comments on this entry are closed }

Myth Busting with Ben Tomhave

by Branden Williams on January 13, 2012

in SBN

I love our industry! There is no shortage of truly talented and smart folks, and one of the best parts of being in this industry is getting to have conversations with these folks often. Ben Tomhave (@falconsview), a noted security pro and blogger, kicked off a fury of tweets that really went into two directions. First was for a common myth about PCI DSS validation which I will address here (and ensure it is much clearer in the next edition of the book). “Can merchants (including Level 1) self assess?” lead us to a conversation about the functions of audit, the industry in general, and corporate responsibility. We’ll get into THAT discussion next week.

The discussion on Twitter began with this tweet:

@ @ @ is it really true that an ISA can certify a RoC, replacing the role of a QSA? thought still needed QSA?
@falconsview
Ben Tomhave

Here’s a basic summary of the conversation (fyi, the tweets are all public if you want to go back and look—some were edited to help the conversation flow in this format):

Me:  That is correct. Merchants have always been able to self certify. Service providers cannot. (brand rules)

Ben: what do you mean “always”? where is that written? thought it was mandatory for L1/L2 merchants to have a QSA?

Me: It’s written in the payment brand level definitions and required validation procedures. MC now requires ISA/QSA for L2.

Ben: if that’s true, then I don’t understand how we need so many QSAs…? why would anybody opt 2 pay more when cutting corners?

Me: Because merchants incorrectly believe that hiring a QSA accounts for a liability transfer. Plus, with corp accountability, an officer’s signature on the Attestation of Compliance is usually required.

Ben: regardless, it seems to me that there is good financial motive to foster confusion around whether or not QSA is a req. :)

Me: I argue that anyone who says it’s required probably isn’t intelligent enough to do it right anyway :) #proposalintrashcan

Ben: Wow, that’s quite a statement. I would argue that people listen to their auditors+consultants+QSAs a little too much. ;)

Me: I’m right there with you. That’s why those folks should become ISAs so they can call bullshit instead of driving off a cliff.

This is the first part of the discussion which I really enjoyed because not only did we discuss some of the false perceptions around PCI DSS (like using a QSA is a requirement), we also got to rehash some roles and responsibilities. We cover this in the book and I reviewed it in this post. Here’s a summary:

  • Bad-Boys, by davidsonscott15

    The PCI Council (Intent): Only answers questions about the intent of PCI DSS.  Don’t ask about fines, complain merchant levels or the requirement to use a QSA or ISA, or ask if Bit9 will comply with Requirement 5.

  • Payment Brand (Enforcement): Only answers questions about their specific compliance program.  Visa’s CISP, MasterCard’s SDP, American Express’s DSOP, Discover’s DISC, and JCB’s DSP all refer to PCI DSS as the common set of controls, but all have different requirements to comply.  You should ask them about fines or when to submit an SAQ.  Don’t ask them about the intent of a PCI requirement (though they will likely answer to assist you) or if RSA’s SecurID is the only thing that will satisfy Requirement 8.2.  While they may try to assist, I typically see (with one exception) payment brands avoid those discussions, especially when their competitors are present.
  • Acquirer (Enforcement): Most compliance questions are better suited for your acquirer because they are responsible for your actions on the payment network.  Acquirers don’t have all the answers, and you should not ask them if <Insert Your Vendor Here> EV-SSL will comply with Requirement 4.1 (hint… it will) or the intent behind a particular requirement.  Again, they may try to point you in the right direction, but Payment Brands are responsible for enforcement of PCI, and they enforce it on your Acquirer who then enforces it on you.
  • QSA/ISA (Interpretation): Your QSA (or ISA) is an important step in the PCI DSS process.  If you don’t like her, the process is going to be a pain.  Alternatively, if she works well with your company, things will work out much better for everyone in the end.  It’s your QSAs job to weigh all the guidance from the Council and apply it to your individual environment to determine it’s compliance with PCI DSS.  Ask her questions about specific technologies and their compliance in your environment.  Don’t forget to tell her EVERYTHING about the solution.  Context is a real issue with these types of questions.

The Council is viewed as the place where the buck stops simply because they are the focal point of everything that has popped up around this industry. To make matters more complicated, members of the Council work for the payment brands! I’ve had numerous discussions with various members whereby a question posed by me is only asked after I specify if they should answer with their Council hat on, or their day-job hat?

So, to review the myth busting, all merchants have the option to self assess, QSAs may get things wrong from time to time, and becoming an Internal Security Assessor (ISA)—regardless of your plans to self assess—is hugely beneficial to your company.

Possibly Related Posts:


Share

{ Comments on this entry are closed }

Links from 2012-01-07 through 2012-01-11

by Branden Williams on January 11, 2012

in SBN

Links from 2012-01-07 through 2012-01-11:

Possibly Related Posts:


Share

{ Comments on this entry are closed }

We Must Hunt

by Branden Williams on January 11, 2012

in SBN

Security people are often viewed as gatherers. We gather security event data, collect logs for review, build documentation based on information about our environment, and group informational assets in like-valued groups to focus our defenses. I think we’ve got the gathering part down. It’s similar to our propensity to react. We may not be great at reacting (or more likely, we’re great at reacting at only a few things), but we get plenty of exposure to it.

Warning!!!...Tiger in training...:O)), by Keven Law

You cannot be a successful security professional by only being a gatherer, and your team won’t be successful if you only hire and employ gatherers. Just like most societal norms that evolved over thousands of years, you need hunters to fill a need that your gatherers simply cannot.

Information security hunters aren’t reacting to incidents, amassing event data, or collecting things, they are taking all that has been gathered, augmenting it with other intelligence sources, and actively looking for threats against informational assets. These guys use complex analytics to find the bad guys when they hide in plain sight.

In this game of cat and mouse you can either sit back and wait—hoping you catch something early enough in the kill chain to save your job and company—or you can take your future into your hands and discover compromises before exfiltration.  Collecting the massive amounts of data we need to do our job allows us to not only be gatherers of information events, but hunters with added analytics.

Think back to the kill chain. We must assume that the first two or three steps will happen (recon, weaponization, and delivery), and are probably largely out of our control. Hunters back up their efforts to focus on exploitation and command and control, looking for and fixing these such that exfiltration doesn’t happen. Passive gathering is great, but without active analytics you are more likely to get the phone call informing you of your breach instead of you finding and stopping it on your own.

 

Possibly Related Posts:


Share

{ Comments on this entry are closed }

Contextual Deep Content Inspection for Security

by Branden Williams on January 6, 2012

in SBN

It’s 2012 (didn’t I already say that on Wednesday?) and the reality of 2011′s shifting security landscape should have set in by now. As much as many of you may want to go back to the days of worrying about Anti-Virus definition files, basic patching, and a single border firewall as the makeup of your entire security posture, its time to take a serious look at how you will plan your defenses for 2012.

One defensive technologies that is getting another look is Data-Loss Prevention (DLP)1. By itself, an implementation of DLP can go a long way to prevent serious issues in simple to moderately complex IT environments—but the bad guys are better than that. They know ways to hide the ex-filtration of information in ways that will look like legitimate traffic to your porous border controls.

Civilian Technician Inspects Circuit Board at Army Aviation Centre Middle Wallop, by UK Ministry of Defence

Corporate IT users today have an unjustified sense of entitlement. They feel they are entitled to use corporate assets for whatever they wish, regardless if it contributes to their job or not. How many corporate citizens with company-issued phones have called or texted loved ones? How about the week after thanksgiving—shop much? Every corporate user is guilty of doing this because we’ve let them do it for years. And why not? The environment ten years ago was nothing like today! Browsing most websites wasn’t a big deal—except for productivity levels of course—and the worst IT offenders were typically handled by HR after we investigated their usage.

In the last several years, we’ve seen more companies deploy filtering products to help protect their IT assets against known threats. DLP is one of those, but as with many walls, it needs help to be effective. Many companies block popular personal email and social media sites because they fear accidental (or intentional) information disclosure. I’m sure that every new site added to a “block list” creates a flurry of hate directed back toward IT and IS.

The use of corporate IT systems is a privilege, not a right.

Let’s say that you deployed DLP on your network to watch for certain types of information entering and leaving your infrastructure. What happens when a legitimate user goes to an SSL-enabled site to purchase something? Do you proxy your SSL and inspect it? Do you match the URL against an “OK to use” list? What about a site that presents an SSL certificate, but isn’t known to be a legitimate website and the certificate is self-signed? And if you get an agent to the user’s corporate desktop, is it actually functioning as an enforcement point or just used for policy violation tracking?

DLP by itself is useful, but it can be so much more effective when paired with a few other controls. Before you can start building and enabling other controls, however, you must know what NORMAL looks like in your infrastructure. Server-to-server traffic is easier to find because it typically has firewall rules associated with it whereas desktop-to-server will just look like SSL or HTTP traffic over ports 443 and 80. Do you proxy your SSL traffic so you can inspect it? If not, consider it. That might be a good way to see if data is being moved while masquerading as legitimate traffic.

filter flower, by tonx

What about other outbound access, do you filter and/or inspect it? Can someone FTP files from your infrastructure to a site somewhere on the net? How about SSH, do you get detailed enough to know the difference between a legitimate HTTP session and someone using SSH over port 80? Do you tie that information back to other anomalies in your environment to provide context to your decision makers? Do you 0nly allow access to sites relevant for business or can someone research products, buy personal airline tickets, and set their fantasy football lineup from their corporate device?

DLP as a technology has been beat up over the years as a luxury product that doesn’t deliver upon expectations. Sure, every DLP solution out there has positives and negatives, but that’s because it’s not a silver bullet technology. It is one of the many tools you need in order to really do this stuff the right way. Deploying it well is preventative work—a type of work we should prioritize as it leads to less unplanned work down the road2.

Possibly Related Posts:


  1. John Kindervag from Forrester just released some research on Rethinking DLP that is pretty interesting as well, especially his DLP Maturity Grid.
  2. I’m implementing a Personal Kanban system right now, and reminiscing of my days of The Goal.

Share

{ Comments on this entry are closed }