Archive for the 'Risk' Category

Jan 25 2012

Kill pcAnywhere right now!

If you haven’t already heard, the code base for Symantec’s pcAnywhere was stolen in 2006, and bad guys are now using that code against the installed base of users in the wild.  This sort of compromise really isn’t anything that new or different.  But what is different is that Symantec is now telling users to flat out disable pcAnywhere until a fix is released.  Which is a good, smart move, but a better move would be to remove pcAnywhere and never, ever start it up again!

I remember the first time I used pcAnywhere; I was working my first helpdesk job and they let me finish part of my shift from home when I was doing mail server work, I could start up the scripts on the server, drive home and finish my work from there.  Being pcAnywhere, every couple of times I’d also have to drive back to work because the program would crash, but hey, an 80% success rate wasn’t too bad at the time.

Fast forward a decade (and more) to when I’m a QSA and pcAnywhere is still out there, and in all too many cases, it’s actually the same version I was using, or nearly the same vintage.  But it’s not me using it to manage a OS/2 Warp mail server (yes, OS/2 Warp), it’s being used to manage Point of Sales (POS) systems all across the US.  You see, mom and pop stores with POS systems don’t have a clue on how to set up a computer, so they find a nice, local service provider who will set up the POS for them, trouble shoot it when they have problems and just generally manage the system for a price.

Herein lies the problem.  If you’re a small, local service provider who makes their living servicing these folks, you have to be able to work quickly and cheaply with clients in a large are if you’re going to make a living.  You need to be able to get on their systems quickly to troubleshot problems and get them back online.  So of course you use a remote desktop client like pcAnywhere and you’re going to leave it directly exposed to the Internet since that’s the easiest way to make sure it’s always available and you don’t have to do a lot of troubleshooting of network equipment.  And you probably use the same password on all your clients, since you don’t want to have to rely on having the right password written down somewhere when the client calls screaming that they’re system is down.  After all, no one would scan for open pcAnywhere servers, nor would they guess the user name is ‘admin’ and the passphrase is “Let me in!” (at least it has complexity).  And you don’t worry about changing passwords when an employee leaves or updating to the latest patch levels.  In other words, a security nightmare.

In 2009, when I worked for Trustwave, one of the things that annual security report dug into was some of the repercussions of this type of remote management of POS systems.  And no surprise, one of the things they discovered was that remote desktop applications like pcAnywhere were one of the leading causes of small business compromises, especially compromises that involved either small chains or a group of geographically close stores.  An attacker would scan for the remote desktop client and then brute force the password and spread out to the other clients of the service provider.  Soon you’d have a whole segment of the local merchant community who’d been compromised and didn’t know how or why it’d happened.  And things have not gotten better since then.

I doubt things will change, I doubt most of the people who actually use pcAnywhere as a tool are going to even notice or read Symantec’s posting.  It’s the only way that the current business model works, not just in the merchant community, but in many other small business communities as well.  The service provider model requires remote tools, otherwise the travel time to and from locations kills any chance of making a profit.  Which means the folks who want compromise systems and steal credit cards are going to continue to have access to the remote desktop solutions. 

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

One response so far

Dec 26 2011

Open Tabs 12/26/11

Christmas is over!  I hope yours was good, but I personally find the whole build up and let down stressful and I’m glad when it’s done with.  Especially the part where my kids are home from school for a week and whine every time I tell them to get out of the house for a little while before I have to hurt them.  Not that I’d actually hurt my kids, but it’s sometimes the only threat that will get them moving. 

There have been some interesting stories leading up to Christmas and it’ll be interesting to see what’s been happening behind the scenes while the majority of us have been chomping on candy and ripping open our presents.  I have nothing to support the theory yet, but I strongly suspect most of the bad guys left their tools running while they took some time off, so their might be reports of compromises in the not too distant future.  After all, there were a couple of reports that came out before the weekend, perhaps hoping to get ignored and bypassed in Christmas craziness.

A quick thought on the boycott of GoDaddy over the SOPA legislation.  GoDaddy is such a minor player in this realm and probably signed on to the legislation like a little brother following his older brother, Big Media; they wanted to sound and act cool in the eyes of everyone else without having the faintest idea that what they were doing had real world consequences.  Boycotting GoDaddy is like bullying the little brother when what you really want to do is punch the elder brother in the eye!  It’s ineffective, both in the long run and in the short term, to boycott GoDaddy when what we should really be doing is making the larger players behind SOPA aware this is an evil and unacceptable way to try to regulate the internet.  A crowdsourced version of the list of supporters on the list is available as a Google doc.  If you really want to do something important, boycott some of the big boys on the list and quit going to their movies and buying their products. 

Open Tabs – 12/26/11

  • Chinese computer hackers hit U.S. Chamber of Commerce – I wonder what our hackers are doing to the Chinese behind the scenes.  Not the vocal ones on the con scene, the ones employed by the Three Letter Agencies.  Never mind, we don’t do that, do we.
  • LOIC (Low Orbit Ion Cannon) – DoS attacking tool – The tool is old news, but this is a pretty good writeup.  If you want to know more though, one of my co-workers could tell you a few things more about how it works.
  • The Thought Leader … One year later – Chris Eng’s further harpooning of the information security thought leaders.  I know about half of the video applies to me at least as much as it does anyone else. 
  • How hackers gave Subway a $30 million lesson in point-of-sale security – There’s another meaning for POS, especially when you don’t bother changing default passwords and trust owners to follow procedures.
  • The Dark side of B-Sides – I’m staying out of this fight, since I know all the players.  But I know there’s a lot of truth to both sides of the stories, and the sooner this can be opened up and the aired out, the better for everyone involved.
  • Hackers steal data on millions of Chinese net users – No need for nefarious government hackers when criminals will hack into Chinese sites because they data they hold might be worth something.
  • Insurance against cyber attacks expected to boom – Let’s just insure our systems rather than taking the time to secure them!  Because the insurance companies won’t place caveats on what’s ensured and what constitutes a breach of contract to include poor maintenance control, will they?  “What do you mean our insurance doesn’t cover this?” is a phrase I expect to hear once cyber insurance (I shudder at the name) becomes common place.
  • Congress calls on Twitter to block Taliban – Oh yeah, because it takes so much to set up another account and tell everyone to go there instead.  And because censorship should always be one of the first tools used by a free, democratic system.  These people spend too much time thinking in hyperbole and too little time thinking in reality.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

Dec 12 2011

Open Tabs 12/12/11

Published by under Blogging,Government,Privacy,Risk

Usually I try to find the time to blog first thing in the morning, but today was way too busy to allow for anything nearly as relaxing as blogging.  I spent two days traveling to and from a client site last week and then two more days at the BayThreat conference, with only Sunday at home to relax and play Skyrim … I mean spend with the family.  BayThreat was a ton of fun; my co-worker Mike Smith gave a presentation called “Zerging is for Chumps” and another friend, Gillis Jones gave his first talk, “Show me the Money”, just to name a few.  It’s interesting to go to a convention where you can almost talk to every attendee if you put your mind to it.  And you know I gave it a pretty good try.  Anyway, I’m off for more flying around the country again this week and have a ton to do in the mean time, so this may be the only chance I get to post this week, other than the podcast.  Presuming I can get that done with Zach this week.

Open tabs, 12/12/11:

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

Nov 28 2011

Curing the Credit Card Cancer

Published by under PCI,Risk

Back when I was a Qualified Security Assessor (QSA), all of four months ago, I often explained credit card data as an infectious disease.  Whatever your credit card data touches is pulled into scope, requiring the full set of Payment Card Industry (PCI) Data Security Standards (DSS) to be applied to those systems to the same degree that the systems processing the transactions are.  That’s because the scope of PCI compliance is defined as “any system that stores, processes or transmits cardholder data and all systems connected to these systems“.  In other words, the switch that stands between your firewall and your processing server is in scope for PCI as are all the systems attached to that switch, unless you take specific steps to control the traffic between the two systems.  Thinking about the credit card data as an infectious agent makes sense, since the data infects everything it touches with the need for compliance and assessment, even though the system may have nothing at all to do with card processing and only made the error of being on the wrong network segment at the wrong time.

Lately though, I’ve begun thinking of credit card data as a cancer instead of simply a disease.  Consider the fact that many security departments spend hundreds of man hours each and every year trying to segment their cardholder data environment from the rest of the network to limit the impact of the annual assessment.  They modify firewall rules, implement VLAN’s, cut off access and chase down every data flow they can think of and find in order to find credit card data and prevent it from infecting systems and bringing them into scope.  Yet every year the QSA comes in and finds data where it shouldn’t be and people with access to the data who have no business reason to have it.  The credit card data continuously spreads and expands scope, and leaving even the littlest bit behind still offers the chance of the scope of the assessment and responsibility to the Data Security Standards.

Why does this continue to happen?  As security professionals, we try hard to find out where the credit card data is at, but the reality is that all too often we don’t understand the thought processes that went into the business processes that created the data flows, and neither do all to many of the people who created the business processes.  We might understand the process that takes a credit card from the customer’s browser to our web server and back to our database server, but the clearance and settlement processes are often an arcane process that we haven’t mastered and can’t figure out how to do securely with our acquiring banks.  I mean, why is it that some processors still mandate that the settlement files be sent clear text over a leased line or the Internet?  And getting them to change that can, very literally, take years to happen.  Another process that we often forget and creates no end of headaches is the fraud control portion of the business; I’ve seen more than a few businesses that had no idea that their fraud prevention team had either full access to the cardholder database or had a portion of the feed that included credit card numbers sent to them daily or weekly.  And since these teams weren’t considered during the original scoping, it often means a whole new section of the business that has to be considered and remediated, costing valuable time and money.

Another factor is how little it costs a department to ask for a stream from the database and how strongly they’ll defend it once they have the data.  I’ve run into many departments in the past that had little or no immediate need for accessing credit card data, but wanted every bit of the information from the web server and point of sales devices, simply because it might one day be valuable to them.  And even if the data is being used now, if there is some value for them to have it today, all to often that department isn’t the one that’s actually paying the cost of processing and storing the data; the IT or Security department received a mandate to make to make the data available and no additional funds were provided to secure the cardholder data in a manner compliant with the PCI DSS.  Good luck getting them to pay for something they’ve had access to for years or give up this access, despite the fact it might cost the company millions and have almost no real return on investment.

So how do we excise the cancer that is credit card information from our enterprises?  I know it’s a bit cliched to say it, but we still need to understand our businesses better.  Yes, our managers are getting better at talking to their managers, but the fact is, when you get down to the actual data flows, managers are simply a set of filters that help the people who’re doing the actual work misunderstand each other better.  It’s just as important to understand the overarching business flows as it is to understand the actual tables and fields that are being copied from one database to another.  Digging into the nitty gritty of each data transformation and export to another department’s database is hard work, made harder by the fact it’s changing all the time.  Managers need to set the policies and procedures that dictate who has access to data, including the where and why, but the line level security folks need to be able to track down the data flows and enforce the policies set up by the people higher in the chain of command. 

Departments also need to understand that there is a cost, associated with cardholder data and need to be made to bear that cost directly.  As long as they simply have to ask for the data and work the political process to get it without paying a fiscal cost, they well.  Policies and procedures are easy to circumvent if a someone in Marketing or Sales puts their mind to it, but when that same person is given a price tag for the data, the need often disappears or becomes something much more manageable and doesn’t include the cancerous data like credit card numbers and expiration dates.  This is a step that only management can take and in many organizations it’s incredibly difficult, since the concept of having to pay for data is foreign to most of the business.  But as long as someone else is paying for it or the cost of data is indirect, people will continue to ask for it.

The real, long term cure to the credit card cancer is to change the rules of the game so that businesses never have access to the credit card information to begin with.  Face it, as long as a single record remains on your enterprise, someone will find a way to get access to it and spread the contagion from system to system.  The solution that’s available to businesses today are various forms of tokenization.  First, on-site tokenization allows businesses to create a ‘toxic waste dump’ in their environment with strong controls around it and only people who have demonstrable business reason are allowed to detokenize the data.  Since there is a more limited number of people who have access in this environment, training on how to treat the data with the caution and respect it deserves is much easier to deliver and enforce.  Plus definitive consequences for treating the cancer causing data unsafely can be enforced when only a limited, educated group of people are allowed to have it.

Even better is to have the data tokenization is having someone else handle credit card authorization and settlement and never let credit card data touch your network in the first place.  Most of the acquiring banks now have partnership with PIN pad manufacturers now with end-to-end encryption built in.  The stores are encrypting the cardholder data as it’s swiped and the register and they either have no access to the credit card information or only have access through a separate backend system.  Online merchants are making more and more use of outsourced payment systems, which also prevent cardholder data from entering enterprises and small businesses alike.  Several of these solutions offer ways to tokenize cardholder data as well.

When it’s all said and done though, it’s the credit card processing system that has to change, not just how businesses treat credit card information.  We need to modify and re-engineer how we take credit cards and remove the monetary motivation for the attack (and defense) on credit card data.  If credit card information has no value for an attacker then attention will shift elsewhere and the security department will once again be able to concentrate on securing the entire enterprise rather than just a small portion that has a compliance measure behind it mandating minimum security standards.  Of course, then we’ll have to worry about what we can use to get funding from management to secure the rest of the business.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

5 responses so far

Nov 22 2011

Open tabs 11/22/11

Published by under Family,Hacking,PCI,Risk

I got home Sunday from 3 days in Las Vegas, two of which were spent at the first ever Minecon.  For those of you who aren’t the parents of Minecraft addicts or addicts yourselves, it’s a game where you create a whole world then mine it for resources and build just about anything you can imagine.  It’s multiplayer, sometimes massively so, and it’s very easy to set up your own server and be hosting it for the world in a matter of hours.  Unluckily, it may be too easy; people who can barely figure out what their IP address is are setting up servers on their desktops then sharing their systems with friends via Hamachi or simply opening their home network to the world. It’s enough to give a security professional an aneurism!  I wrote up my own experience in creating a cloud server for Minecraft in April, but that server never caught on with the kids.  So now I’m trying a different solution, MineOS Crux, a custom build distribution of Ubuntu specifically created for people who want a secure, lightweight Minecraft installation.  I’m running it as a VM on my Mac Mini server and exposing it to the world on a non-standard port, plus I locked down the distro a little more than the standard build.  I’m still more than a little paranoid about it, so if the kids aren’t using it, it’ll go away.

Oh, and the kids got me to start playing Minecraft as well.  Good thing there are a lot of long holiday weekends coming up.

Open Tabs 11/22/11:

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

Nov 16 2011

Google’s wifi mapping non-solution

Published by under Privacy,Risk,Security Advisories

Google got in a lot of trouble last year for capturing private data from wireless networks when they were driving the googlemobiles around to get video shots for StreetView.  Basically, rather than just capturing the SSID for the access points, in a lot of cases they captured data streams from the AP’s, which violated all sorts of European privacy laws.  And in reply to this, Google came up with a solution:  users can opt-out of Google’s wireless access point mapping solution by simply adding “_nomap” to the end of their SSID!  So simple it’s stupid.  No, I mean it’s so simple it’s absolutely idiotic and a waste of the digital ink that was used to express the idea!

I think MG Siegler expresses it best when he said, “The solution is a joke.“  Siegler thought of the same things I did when he saw this so-called solution.  First, only a fraction of a percent of people are even going to understand that Google is mapping their access points and even a smaller segment of the population is going to understand what that means.  And of that small group, only a much smaller percentage are going to make the changes to SSID names necessary to opt-out of the Google mapping.  I thnk that his .01% of the 10% of the people who actually read the article is a bit generous; only the truly paranoid will opt out using this method, and they probably weren’t advertising their SSID to begin with.

Let’s think about the pain in the arse it is to change a SSID to include ‘_nomap’.  My house is probably not normal, but it’s what I have to use as an example.  I have two wireless networks, two access points, three desktops, half a dozen laptops and a server that all would have to be changed to include the ‘_nomap’ SSID.  Plus there are a few more systems to worry about when you include the gaming systems the kids use.  The average household probably doesn’t have nearly that much equipment, but they also don’t know enough about wifi to set it up with proper encryption in the first place, so why would Google assume the average home user would know enough to change the SSID on all these systems once they finally got them running on their home network?

Let’s be honest; all Google is doing is waving their hands over StreetView in an effort to claim they’re doing something in front of governmental bodies who wouldn’t know the difference between an SSID and Sid Vicious.  In most cases, they’d probably recognize Sid Vicious before they’d have a clue what an SSID was or what it’s used for!  Siegler nails it when he states that Google might as well ask for people to solve calculus problems.  And I’d be willing to guess there are a number of people would have an easier time solving advance mathmatical equations than they would changing their SSID.

I want a solution that doesn’t require me to change my SSID to opt-out of Google’s mapping.  It’s a stupid solution and I’m not changing my SSID to include the ‘_nomap’ modifier.  My last thoguht is two-fold:  What effect will this have on the all the data that Google has already collected (Answer: none) and will Google actually honor their own ‘_nomap’ identifier and drop the data at collection or will they simply not display the access points using ‘_nomap’ but keep the data in their database?  I think you and I both know the answer to the second one as well.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

One response so far

Nov 04 2011

Open Tabs 11/04/11

It’s almost time to hop in the car and head for #BSidesDFW (I even think in hashtags some days) in about an hour.  I find it annoying that I have to leave the house about 3 hours before my flight to have any chance of making it, since it takes 90 minutes to get to the airport and about 45 minutes to get through the TSA checkpoint most of the time.  I was joking around on Twitter earlier this week and said I’d vote for the first Presidential candidate, Republican or Democrat, who promised to abolish the TSA; it turned out that Ron Paul had already made that promise, but we’ll see if he’s still slugging it out by the time the primaries roll around.  In any case, I need to get packed up and head out.  I’m going to try to get a few interviews at BSidesDFW for the podcast, since there are so many interesting people speaking tomorrow. 

Open Tabs 11/04/11:

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

Nov 01 2011

Network Security Podcast, Episode 257

Published by under Hacking,PCI,Podcast,Risk

Tonight Martin is speaking to Josh Corman, Akamai co-worker, and HD Moore, creator of Metasploit and Rapid7 CTO.  Josh came up with the idea of HD Moore’s Law a couple of months ago, the idea that the strength of the casual attacker is roughly equivalent to what Metasploit is capable of.  If your corporation isn’t capable of defending yourself against Metasploit, you’re not going to be able to defend against these casual attacker and you’re going to be wide open to more sophisticated attackers.  Josh explains the concept and what it means to security and HD talks about the fact that Metasploit helps give security teams a measuring stick for their security.

Zach, Rich and Martin are all incredibly busy and are trying to figure out how to fit the podcast into the constraints of our schedules.  We may have to skip a number more weeks between now and the end of the year, but we’re trying desperately to get our lives under control.

Network Security Podcast, Episode 257
Time:  30:09

Show Notes:

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

One response so far

Oct 31 2011

Open tabs 10/31/11

it was a fun Halloween, or at least as much fun as it can be if you spend the whole day home working.  It would have been fun to be in the office today to see my co-workers in their costumes, but I had far to much to do to make the commute to my office.  Tomorrow, however is a different story.  We’ll actually have a podcast this week, since I sat down and talked to HD Moore and Josh Corman about “HD Moore’s Law”.  If you don’t know what that is yet, tune in tomorrow.

Open Tabs 10/31/11

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

Sep 03 2011

Is this really the ‘State of Security’?

Published by under General,Risk,Security Advisories

I’m not a big fan of opinion polls, especially when the people writing them present them as if they were facts, rather than simply opinions of the people polled.  There’s a huge difference between the reality we live in and the way we perceive that reality.  That’s simply a fact of life, not a criticism of anyone in particular.  But it has a huge impact on the real usefulness of data when it’s based on perception rather than a quantifiable measurement.  And in the information security field, we’ve been working on perception and intuition for far to long and need to start relying on real, measurable data instead.  I have been told I’m too hard on polls, since opinions are valid data points as well, but I’m not so certain.

That’s quite an opening statement for a look at the latest security survey by Symantec, but I wanted to get my own personal biases out of the way before starting.  It also help explain some of my skepticism of the value of the Symantec State of Security 2011 report.  It’s pretty, it’s glossy, it has nice pictures, but it’s still an opinion poll and I always have to wonder how much it’s been affected by the perception of the people who were surveyed, how much they were willing to answer honestly and whether or not they actually knew the answers or just made stuff up.  As I said, I’m not a big fan of opinion polls in security, in large part because I’ve filled out more than a few of them myself.

There’s a lot of white space, large type and big graphs in the the report.  Padding that should have been replaced with more analysis and discussion rather than being wasted.  Which tells me this was probably produced by the marketing department rather than someone in engineering or security.  Marketing might have gotten the analysis right, but the 19 pages would have been boiled down to 8 or 10 pages if it had been written by an engineer instead.  That’s not to say there isn’t some good information in the report, but it does mean there’s a lot of fluff to wade through to get to it.

One of the important tidbits is that, according to the poll, 41% of security professionals feel that security has become more important to their businesses over the last year as opposed to 15% who think it’s decreased in importance.  Given some of the high profile attacks that we’ve seen in the last year, I don’t find that surprising, but I’m still glad to see that what we do is gaining in awareness of management.   41% of respondents also feel that they’re being given more budget, which leads me to ask if the increase in awareness is leading to a greater budget or if an increased budget lead to a feeling of more awareness?  Given how long we’ve been underspending on security, it is good to see some positive movement on this front.

I found the trends that are driving security concerns a little confusing.  According to Symantec, mobile computing, social media and consumerization of IT top the list of concerns; this was explained to me as coming from the newness of the technologies, but I find that hard to swallow.  Smart phones aren’t new, social media isn’t new and consumerization certainly isn’t new.  I know I had to deal with consumer products in the workplace when I was a sysadmin and that’s been nearly a decade.  The first thing I’d point out is that there’s only a 4% difference between the top 6 items in the list and Symantec acknowledges a 5% margin of error in the survey.  Which means that nearly any one of those categories could actually be the biggest security concern.  I’m a little surprised they split different aspects of ‘cloud computing’ into various subcategories such as SaaS, PaaS, public and private cloud, but I mean that in a good way.  It’s so nice to see someone who actually realizes that the ‘Cloud’ isn’t one technology but a collection of very loosely related technologies and implementations. 

I would like know more about how the question concerning significant security threats was posed to the people polled.  Hackers top the list, but there’s also a category for hacktivism, criminals, industrial espionage, targeted attacks and state-sponsored attacks.   I see those all as potentially falling under ‘hacking’ which could mean that there was a flaw in the question asked that biased the results.  I’m also not sure how this perception actually gains us any understanding in the first place.

“71% of respondents saw an attack in the last year…”  Oh boy, that’s a loaded statement.  If only 71% of the companies saw an attack, what were the other 29% doing, because I’m absolutely certain they were attacked, even if it was simply a drive-by attempt.  Were they playing ostrich, with their heads buried in the sand and no detective measures on their network?  Did they have anti-virus and ignore the malicious code that found it’s way into their network or did they not have AV at all?  Were they actually looking at the logs from their IDS or were they ignoring those as well.  I’ve run into more than a few security professionals who’ve said their management didn’t want detective measures  in the environment because detection would mean they’d have to do something about it.  But even I have a hard time believing it was 29% of the companies. 

The one perception I find in this report that I find scary is the measure of what security professionals think they’re doing well.  52% of security professionals polled believe they’re addressing routine security measure effectively.  But that also means 48% of security professionals don’t think they are.  Close to half of us are willing to admit we aren’t doing a good job at the basics.  And that was the highest measurement amongst all the data points.  If half of us admit we aren’t even doing the basics well, is it any wonder that we’ve seen so many breaches in the last couple of years?  Do we even have a chance if half of us admit we don’t have the resources to do the basics?

The recommendations by Symantec are generic and could have come from nearly any security report written in the last few years.  Policy, process, buzzwords don’t help much.  What should have been highlighted is the need to get the basics right, rather than work on policies that most people in your company will never even know exists.  Yes, policy gives us a lever to pry money out of management from time to time, but it doesn’t address the real problems of just being aware of what’s happening on your network.  But that’s probably not what management wants to hear anyway.

Take a little time to read the report, it won’t take you more than 15 minutes to read every word in it.  As with any report there are some nuggets of knowledge to be gained, but question the analysis put forth by Symantec.  I wish they’d included more information about the specific questions asked, because that tells a lot about the biases involved.  I would also like to see hard data points about the points made, rather than just opinions.  But I guess a couple of years of hanging around people like Alex Hutton and Wade Baker, writers of the DBIR, make me value analyzing data over opinion.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

12 responses so far

« Prev - Next »