Fun Article from the Security Catalyst. Full Article Here.
In addition to getting to break things in order to help our customers prevent assorted miscreants from doing so, one of the many hats I wear at QuietMove is the amorphous responsibility of ‘business development.’ In English, that means I identify organizations that could benefit from our services, sometimes travel to visit them, often buy them lunch, and explore ways we can help them. Though my background is technical, it’s something I’ve really grown to enjoy because I find it interesting to learn about different industries and business models and their unique security challenges.
That said, I’m often surprised by some of the organizations I visit â€“ it’s shocking that some of the largest organizations in critical economic sectors don’t have security organizations, don’t have security programs, and don’t even have a single person for whom ‘security’ is part of their job description. In other cases, there’s a single ‘security’ person with no budget, staff, or authority. I’ve been that guy, so if that’s you, I feel your pain. I’d like to share an anecdote with you about a large company I visited last week who is in the former category â€“ no security organization at all. If your organization has no security-focused staff, or if you’re the one guy or gal whose shoulders it all falls on, I’m also going to share a strategy for moving your organization in the right direction.
It was a pretty exciting morning â€“ I was heading to an initial face-to-face meeting with a potential customer, one of the largest mining companies in the world. My initial contact was with a gentleman who managed their server environment. At my urging he also invited their application and network team. The meeting was scheduled to discuss assessment activities â€“ something they haven’t been doing, and didn’t have the expertise or tools to do in-house. I asked him to invite the other managers because it was important to get their buy-in, and also because our customers get the best value when we test all attackable surface areas.
What I heard during the meeting was one of the variations on a common theme – each group ‘owned security’ for their sphere of responsibility, but there were no overarching standards, and minimal to no coordination. These guys were all professionals â€“ the problem was organizational. Their company didn’t see a need for dedicated security resources.
Well OK, almost all professionals. One of them questioned what they had that was worth someone breaking in to steal. The look from his colleagues was as if he said his company possessed nothing of value, which is more or less what he said.
I pointed out a few things â€“ they’re a mining company, so the list of what sites they are considering buying or leasing because their geological analysis said it would be a good spot was definitely worth something to their international competitors. Also valuable are their supplier lists, customer lists, and employee information, not to mention their reputation.
If it’s Everybody’s Job, it’s Nobody’s Job
Those who know me well, know I have a tendency to devolve a conversation into pedantic comparisons to obscure philosophical and/or historical topics. Lucky for you, Dear Readers, I’m too much of a lazy typist to inflict this habit on you â€“ for too long.
The attitude at the mining company I visited was that security was â€œeveryone’sâ€ job. That may be, but without guidance from an accountable party, there is no incentive for anyone to perform something that they aren’t being measured against.
I’d like to paint a comparison to the relative physical security of a shopping mall vs. a public street. Shopping malls have a financial incentive to police their premises. After all, most people wouldn’t visit a mall after being mugged at spork-point in the food court after the first time, forget about the second. As a result, mall owners will set stricter codes of acceptable behavior on their premises than you’d see on a city street. Meanwhile people will litter the ground with cigarette butts, soda cans, and chewing gum in public places with a frequency you’d never see in their own home.
This is an important side effect of the concept of private property â€“ with ownership comes responsibility. We see the same attitude in the workplace â€“ when security is the responsibility of ‘everyone,’ it’s really owned by no one. People are measured on the performance of their primary job responsibility â€“ meeting development deadlines, system uptime, etc. There is no central coordination of standards, no one who ‘owns’ testing controls, no security metrics, and ultimately little to no security.
Create a Security Team for $4.95, Plus Tax
That’s about the going rate for a dozen donuts. Yes, it’s that easy.
Back to the mining company â€“ I realized that they had a long way to go. Since they didn’t have enough management buy-in for security to form a security organization, had no budget, and no ownership of responsibility, I shared a strategy whereby they could create one using the resources they have available now â€“ themselves.
My suggestion was to pick trusted, interested persons as Single Points of Contact (SPOC) from key parts of their organization, schedule a conference room plus a dial-in conference bridge number for those at different locations, and invite them all to an informal monthly brown-bag lunch.
Pick out a news story related to a security incident or breach at another company from the news – a good place to look is the SC Magazine Breach Blog – and email it to everyone ahead of time. The purpose of the monthly lunch is to do some tabletop war gaming. What you’ll want to discuss is, if a similar incident affected your organization, how would you respond? What controls are in place to detect it? Who would be notified? What actions would be taken?
There are three goals for your Computer Incident Response Team (CIRT) meeting:
1. Identify a Single Point of Contact (SPOC) and backup contact for each part of the organization that should be involved in an incident or breach. In addition to identifying a contact and backup from system administration and network teams, don’t forget to pick points of contact from groups like telecom, finance, human resources, public relations, physical plant security, and any other towers you think you can pull in. Make a phone list, including cell phone numbers, and distribute it to all members.
2. Build an ad-hoc team that can respond to incidents, by building rapport and familiarity. This is an important point â€“ a phone tree does not a team make. The team will learn to work together, and learn what roles they can play in incident response.
3. When (not if) an incident affects your organization, you will have already run through similar scenarios in your tabletop wargaming exercises. You’ll have a response team consisting of members of each part of your organization that might be affected. Most importantly, you’ll have the resources to effect a coordinated response.
Don’t forget the donuts.