Go listen here.
Thanks again to Alan and Mitchell for having me on the panel.Â And thanks to the panel for a great discussion.
Go listen here.
Thanks again to Alan and Mitchell for having me on the panel.Â And thanks to the panel for a great discussion.
I forgot to mention that I was a guest panelist on Alan Shimel’s SSAATY podcast last night.Â This was a great panel.Â I had a great time, and I think we really hit some key points and offered some solutions to security admins and managers out there that need some help selling security to execs.
The panel consisted of yours truly along with Martin McKeay (Network Security Blog, ComputerWorld),Â Bobby Dominguez (Sykes) and Mike Rothman (SecurityIncite, NetworkWorld).Â It was hosted by Alan and Mitchell, two of the best podcast hosts I know, and though I have never met either face to face, I know they are both good guys.
One person that was scheduled but ran into some emergency security management duties was Michael from mcwresearch.com.Â I understand why he couldn’t be there, but I really missed his insight.Â I would have loved to hear some of his horror stories.
BTW, I was VERY impressed by Bobby Dominguez.Â I have never talked to Bobby, but I figured out very quickly yhat he has a vast amount of experience, expertise, and just plain ol’ smarts.Â You REALLY need to listen to this guy.Â Hopefully he will start a blog soon himself.Â He has a lot to offer the community.
Martin is always good to have on a discussion like this because he has a lot of experience in this area.Â He never ceases to impress.
And Mike Rothman, well…, he’s Mike.Â What else need be said?Â And we actually agreed on something in the podcast, if you can believe it!Â Actually, Mike and I agree onÂ a lot of things.Â We just like to disagree to make it exciting.
And of course, there’s me.Â ‘Nuff said!
Anyway, the podcast should be up soon.Â Go look for it in the next few days at Alan’s blog.
Karn Griffen over at the the Information Security Gurus blog mentions my post about getting out of security management.Â He has a good post today about how we should all be getting out of the front lines when there are so many possibilities with outsourcing.Â He also commented on that same post, where he said the following:
If I can turn on secure networking services, complete with IPS, Virus, Spam filtering, etc. and the company I outsource this to will provide me an SLA that guarantees the service parameters Iâ€™m looking for, why would I bother with a full-time person (or more) to do these things.
While I agree with Karn on this point, the question that comes to my mind is if you can’t convince an exec that security is needed at all, then why would heÂ / she do either?
The big problem is that execs often cannot justify security at all as a cost.Â The ramifications to notÂ spending money on security are still so light.Â Â Much of the legislation out there still does not have teeth.Â The media is getting tired of printing stories about this stuff because readers are tired of it.Â Some non-governmental regs like PCI are starting to get somewhere, but that is not anywhere close to where it needs to be.
So unless you can convince your execs that security is needed, they ain’t gonna spend money on it, no matter if you outsource or insource it.Â
But let’s play devil’s advocate here and assume that all exec’s get smart and buy off on security.Â Then, the SMB exec’s get even smarter and see Karn’s point that they can outsource.Â Where does that leave guys like me getting out of operations and trying to sell security?Â Should IÂ be selling to SMB’s now when I know they would be better served by outsourcing?Â Â Do I sell to MSSP’s?Â Better yet, do I have to start working for MSSP’s, sitting in a chair watching packets go by?Â Do I lose even that job to ever-more sophisticated UTMs / IPSs / heuristic filters that can figure this stuff out better than I can?Â Does the UTM take over for those MSSPs where there are only 2 or 3 viable options for them to filter traffic for their clients, essentially killing much of the security market?Â Â Are the enterprise-type clients enough to hold up the market?Â Does the technology get so good that even enterprise clients can use it?Â Does my job just go POOF in 5 – 10 years?Â AAAAAAAHHHHHHHHH!!!!!!!!!!!
Karn, you are on to something, but I’m not sure it’s good.Â But good or not, is it inevitable?
Thanks to Mike Rothman for pointing this out.Â Seems like McGruff isÂ trying to take a byte out of cyber crime.Â I haven’t seen McGruff around for a while, but like Mike, he is a familiar icon that was veryÂ effective in crime education.Â I am all for this.
OK, let me start this out with a disclaimer: I am going to work for Accuvant (as most of you know by now since I can’t stop blogging about it), and they are a big Juniper reseller.Â They do not sell Cisco, so they drink the purple Kool-Aid.Â Also,Â I am a fan of Juniper when it comes to many of their security products (I love their SSL VPN and their firewall / VPN devices, but their IPS leaves something to be desired).Â All that being said, you might think I am going to say something positive about this dealÂ between Juniper andÂ Symantec.Â Well, you’re right and wrong.
First, I agree with Mike Rothman’s comments:
…adding Symantec’s anti-spam, IPS signatures, and vulnerability research to Juniper’s products will make them better and I think it will actually happen. Why wouldn’t Juniper do this, given they are pretty much irrelevant in the IPS space and don’t really have a compelling UTM platform? They’ve got nothing to lose.
I also agree with Mike that this mostly comes from a “We Hate Cisco” reaction.Â I don’t think Cisco is the best out there in most things that they do.Â They do many things decently, but they are not the top in quality.Â But they ARE Cisco, and they are taking so much of the market for the simple fact that nobody ever got fired for buying Cisco.
The fact that Richard Stiennon hates this dealÂ is not surprising.Â Stiennon is negative on just about anything that ever happens in security nowdays simply because he doesn’t agree with the direction security is taking, namely “host plus network security”.Â However, his perspective that Juniper and Symantec have not taken advantage of opportunities given to them is correct.Â Symantec is the epitome of the “bumbling giant”.Â I don’t think Juniper is anywhere close to that yet, but Stiennon has to lump them in because, again, he is negative about anything to do with NAC, UTM, etc.
I don’t like this deal because it is with Symantec.Â I just don’t like how Symantec works and I don’t like John ThompsonÂ (especially after his keynote at RSA 2005).Â But I like this deal from the fact that it can help Juniper leverage Symantec’s knowledge.Â Juniper NEEDS to become a premier security knowledge source on the par of Symantec or TippingPoint if they ever hope to be completely respected in this arena.Â Building boxes ain’t gonna do it.Â What I am hoping is that they use SymantecÂ to maybe help them learn how to do this themselves.
…is crap like this.Â I am honestly tired of having to worry about keeping up with the latest security flaw and making sure my IPS has the latest filters and trying to make sure my network admin is keeping the patches up to date and yada yada yada.Â It just gets old.
A while back, I published a list of all the things I do on a daily / weekly / monthly basis as a security manager.Â When I look back at that list, I am seeing about nine tenths of it as reactionary chores.Â AndÂ I am tired of beingÂ in such a state of constant reaction, even when I do everything I can to be proactive.Â It just gets old.Â
I realize this may sound discouraging.Â Believe me when I say I don’t want to give up the fight.Â Â I just want to help some other people fight the fight instead of being on the front lines every day.Â
When IÂ first thoughtÂ about it, it kinda felt like the front line troops were going to lose a man to battle fatigue.Â But to clarify by carrying the military analogy a little further, think of me as aÂ REMF (ask your military buddies – they know what that stands for).Â Basically, REMF’s are the people who sit in the back away from the front lines.Â They drive fuel trucks, they fix broken vehicles, they cook food, deliver MRE’s, deliver ammunition, etc.Â They are support.Â They don’t always get a lot of respect.Â But without the support the REMF provides, the grunt, the M1A1 tank crewman, the Apache pilot, and the howitzer gunner can’t fight the fight.Â So you gotta love the REMF, even if he is not looking at bullets every day.
It may sound like I am trying to convince myself that I am making a good move, and to some degree I probably am.Â I know this is the move I am supposed to make.Â I feel that deeply.Â I just want people to know that I am not giving up.Â I am just moving to the back lines.Â Is there some fatigue?Â You betcha.Â But I am not going to be the guy who Patton slaps.Â I’m gonna be the guy driving the ammunition to the front line so you can shoot at the bad guys.
Of course, if the guy who brings the ammunition had to convince the tank commander every time that his ammunition was better than that other guys ammunition, and that his ammunition fit better in the gun tube and would make pretty lights when he shot it down range, then our military would be in a bad way.Â OK, so maybe the analogy doesn’t play all the way through, but work with me here, OK?
Let’s look at a scenario.
Most security managers will limit the ports users can use going out to the Internet. You typically allow http and https, and maybe ftp. It just doesn’t make sense to allow “Any” out to the Internet. This will limit your attack vectors by not allowing IRC and other such dangerous protocols. There are also other things you can do to block what the firewall won’t see (protocol blocking, proxying, layer 7 filtering, etc.).
In the same manner, most organizations block incoming ports as well if they are not needed. Why allow http or ftp traffic in if you don’t have a web or FTP server? But if you do have these types of servers on your network, you might implement another layer of security by using non-standard ports on your webservers to help combat ID theft and other attacks. Basically, instead of using port 443 for SSL, you might set something like 8000 or 8700 or 8900… And many security admins and managers attest to the success of this approach. They claim to see fewer attacks because your typical script kiddy is going to be using scanning tools to look for standard ports and will just skip over those sites without those ports. Makes sense. Colleges and universities are a big advocate and user of this approach.
But what about the security admin / manager who practices limits the ports his users have access to but also has a user staff with a high percentage of professionals who have to access those very schools and other organizations that implement this type of security by obscurity (SBO)? Many are working on their degrees. Many are researchers that have regular access into university networks. These are legitimate needs for these types of professionals, so he can’t say “too bad, do your work at home”. If they were all accessing one or two different networks, then no big deal, but it just ain’t that simple.
What you have here is a “security collision”.
Basically, the security manager of the organization with staff trying to access these sites using SBO has to open ports to allow the traffic. But then you cause potential security problems because malicious insiders and malware (bots, etc.) might take advantage of those ports. So you try to limit that exposure by narrowly defining the policies by using specific source and destination IPs in the policy. That becomes a headache quickly because of the sheer number of policies this has the potential of creating. So what is this security manager to do?
Looking at this narrowly, SBO raises it’s head as the issue. I have spoken for SBO in the past, and I continue to think it is a legitimate tool in the security managers arsenal. Some people argue that if you have appropriate security measures in place you won’t need it. I contend that SBO can be one of those “appropriate security measures” and you should have layers. But it can cause headaches for others. Should that deter the security manager from using it? Probably not. You have to look out for you data and network first (and if some admin from another company calls me and starts griping that I am using non-standard ports, and it is causing him headaches, he might find himself on the “blocked IP” list quickly).
However, the above scenario is merely an example of the problem. There are other security collision problems out there.
Another example is caused by the fight against spam, namely reverse DNS lookups. Here is an excerpt from this 2004 Security Focus article:
1.4.1 Host-less and vanity domains
The reverse lookup approach requires email to originate from a known and trusted mail server located at a well-known IP address (the reverse-MX record). Unfortunately, the majority of domain names are not associated with static IP addresses. Omitting cyber squatters, the general case includes individuals and small companies that want to use their own domain rather than their ISP’s, but cannot afford their own static IP address and mail server. DNS registration hosts, such as GoDaddy, provide free mail forwarding services to people that register host-less or vanity domains. Although these mail forwarding services can manage incoming email, they do not offer free out-going email access.
Reverse-lookup solutions cause a few problems for these host-less and vanity domain users:
- No reverse-MX record. People sending email from a host-less or vanity domain simply configure their mail application to send email from their registered domain name. Unfortunately, a lookup of the sender’s IP address will not find the sender’s domain, and a lookup of the sender’s domain may not find the correct reverse-MX record. The former is particularly common for mobile, dialup, and other users that frequently change IP addresses.
- No outgoing mail. One possible solution requires relaying all outgoing email through the ISP’s SMTP server. This would provide a valid reverse-MX record for sending email. Unfortunately, many ISP’s do not permit relaying when the sender’s domain is not the same as the ISP’s domain.
In both cases, someone that uses a vanity domain, or a domain that does not have its own mail server, will be blocked by reverse-lookup systems.
This may not be a huge problem, but I have seen a couple of problems caused by this over my years in IT and Security.
Many people would say that these problems can be fought by sticking to standards, but baddies often rely on us doing that to make their job easier. That is seen specifically in the first example.
I am not trying to create FUD here – these are just things I see in my job. In reality, I do not think this is some gargantuan issue that we need to start putting a lot of effort into. I think it many of the security collision issues have to be taken care of on a management level. But it something that I and other security managers have to deal with on a fairly regular basis. So what can we do?
Stop waiting for an answer… I’m asking you!
Thanks to the SecurityCurve blog for posting this about Apple.Â The Mac users are going to get hard one day, and they are not going to be prepared.Â Yes, many of them use AV software, but my suspicion is that many do not run it because they don’t see a reason for it.Â Take a look at this post to see if you think I am wrong.Â Though the author admits that it may happen one day, he is just so smug (to use SecurityCurve’s analogy) that his Mac is just wonderfully immune right now.
What I see is this: Malware is more and more specific now days.Â It is written for monetary gain, not for kicks (it is possible someone may write something just to prove Apple wrong, but who knows).Â Apple will get more and more of the market.Â Their servers, because more people are using Macs in business, will start to get more popular (just like with Windows).Â Then more and more valuable data will be stored on Apple servers, and the possibility of monetary gain will increase.Â So the possibilty of malware will increase.
This storyÂ talks about using third-party patches for security flaws instead of waiting for the vendor to put out a patch.Â Personally, I am dead-set against it (IÂ posted a while back about it, but I am too lazy to go look for it) for the same reasons the security pros in this article are against it.Â
And I am sure there are more issues.Â One of the main points brought up in the article is that if you have a good defense-in-depth infrastructure, you can maintain good security without the need to install patches right when they come out.Â One comment struck me:
Using a mitigation strategy like blocking certain ports or shutting certain programs is the better solution. The user may have to go without a feature for a week, but it’s better than taking a risk with a third-party fix that you then have to go and uninstall before installing the real patch.
I couldn’t agree more.Â And if you have a good IPS vendor with a quick signature turn-around, then you can probably have the ports turned back on or the features back in operation much quicker.
I talked about this on Alan Shimel’s podcast a few weeks back as well.Â He asked me what Patch Tuesday was like for a security manager like myself, and I besically told him that it was no big deal really.Â I trusted in the security I had in place.Â I’m not saying I’m invulnerable.Â But locking down the infrastructure and paying attention to current threats and responding to them in a timely manner is the key to stop attacks before patches are available.
Just some random thoughts here on why I write this security blog:
Let it be known that I DO have a SIM in place now, andÂ I have received someÂ value from it.Â I think the value that anyone gets from SIM depends a lot on howÂ your environment and how the SIMÂ is implemented.Â This is the same asÂ any security product.Â Â Is SIM living up to it’s expectations?Â No, it is not.Â I agree with Mike on this point.Â But I do not believe that SIM is dead.Â
So I stand by that assertion that a common reporting standard for security appliances is a good thing, though I agree with Mike that it will be years before this has any real benefit because of the delay of vendors to move on such things.Â I also agree with Mike that SIM does not meet expectations right now.Â Vendors very clearly point out what their product will do and then steer away from those security appliances and products that it will not support, so the ol’ bull shitake meter definitely hits the high scale when they try to push something on me.Â But I don’t think it is a lost cause necessarily.
Here’s a quote from Mike about SIM:
It’s all about being able to 1) prioritize efforts and remediate faster, and 2) crank out a report to keep the auditor happy.Â
The point is that if we can get a common standard, number one can be met.Â Should we just throw out SIM if there is a possibility of having a standard that may give us what we are asking of SIM now?Â No, I don’t think so.Â There can be some valueÂ now if, again, you implement well.Â But the problem here is what Mike says about the timing and when we would see value.Â So if you do not have a SIM yet, I would say do a LOT of research before getting one, and I would possibly recommend against it at this time (and with the advent of UTM’s, you may not need to get one if you go that route).
On point two, I think Mike’s really big analyst’s hat is getting in the way.Â He isÂ forgetting aboutÂ us little people!Â Auditing is a REALITY that I and my fellow security managers have to deal with.Â I am all about securing my network and getting everything else out of my way.Â If I can satisfy and auditor and get him out of my hair by producing aÂ report from a SIM, I am damn sure going to do it.Â If a SIM makes ‘em happy, then I will spend the money.Â That is value to me right there!Â That may not sound fiscally responsible, but the less I have to answer questions from some dude who is reading off of a script, the more time I have to actually do my job.
So overall, I disagree with Mike that the common format is not a good thing.Â I think Mike is trying to throw out SIM when there is a possibility of it actually giving a lot of value later down the road.Â But if you do not have SIM now, take a long, hard look before buying.
You’ve got anywhere from six to 60 security applications and tools in your data center, and most of them work pretty well. There’s just one problem: None of them speak the same language.
ArcSight today attacked that problem by proposing a new log management standard, the Common Event Format, that could enable security devices and applications to present and exchange event data in a common way. The net result: Security managers might soon be able to analyze security incidents from a single screen, without plowing through event logs and data on a dozen different apps or appliances.
Amen brother.Â SIMs were supposed to fix so many problems by pulling logs together and alerting on them.Â But so many devices that spit out syslog messages use different formats, and then the SIM vendor has a choice: either partner with every security vendor out there, or partner with a few but accept syslog and make you create your own alerts.Â Something needs to happen, and badly.Â This os one of the reasons security management outsourcing is becoming so popular.
Since I started blogging, I’ve seen a few people post what blogs they peruse. I guess I’ll hop on that train as well, especially since I just learned how to export my OPML file out of BlogBridge and import it into Bloglines.
There are 60 feeds (this includes news and blogs) pertaining to security that I read. Some of these are rarely updated, some are fairly consistent, and some are in between. Many are common. Some are fairly new and haven’t gained much traction yet. But the sheer amount of opinions and data there is astounding, just in 60 feeds.
So take a look my public Bloglines feed list if you have the inclination.
I saw this article about the rise of image spam, and I started thinking about the image spam I have been receiving. A very high percentage of it (for me) has been stock spam, just like in this article. And the author of the article mentioned that there was a rise in the value of the stock (almost 28%) from the previous day’s closing. This obviously could have been a coincedence, but it got me to thinking.
So, I bought a few penny stocks, connected to my IRC server, got a few bots going,…oh, wait. Sorry, my nefarious personality just reared his head.
Anyway, I thought it would be cool to track the effectiveness of stock spam. Does this actually work? It certainly seems plausible. Unfortunately, I delete all the spam that comes in to me, so I don’t have a good record. I thought I would hit my email gateway’s message log and filter on “stock” to get a list, but that doesn’t work too well because the spammers don’t usually include the actual word “stock” in their emails, and it definitely doesn’t work in image spams.
So, what to do? I don’t want to have to wait too long to gather a bunch of spams, especially since my filter seems to be performing better since I did some tuning. So, I thought I would look around the net for something. Lo and behold, I am not as an original thinker as I thought. Take a look at this site.
Here’s a quick screen shot as well.
Basically, this site is showing the short term gains that a lot of stocks show when a stock spam comes out. It is interesting, but this site shows that almost every stock that has been spammed shows a long term drop. This didn’t surprise me at all, but it is still an interesting point.
I just read this post by Richard Bejtlich at Taosecurity. Basically, a guy was trying to come up with an ROI for security, trying to show management where security adds value in actual dollars. Richard is correct that there really ain’t no such animal.
I have never figured out a way to show my CEO or CFO value for putting in an IPS. I can show how it fills a security gap or helps us comply with HIPAA (though when you come up with a concrete definition for that one, let me know). But I cannot show him that the IPS will pay for itself by adding value to our company. Like Richard points out, security is insurance. The IPS will only pay for itself if it prevents an attack that would have cost the company more than what we paid for the IPS.
Of course, the problem with that argument is that you never really know what an attack would have cost you. Yes, you can quantify an asset and tell the CFO that it will cost the company $50,000 if it is lost. But not many execs put stock in something that MIGHT happen or what it MIGHT have cost. They want numbers.
Watch the video below.Â I have heard and read some stuff about this, but this video really tells the tale.Â It seems professionally done.Â The people all seem very genuine and not actors, or they are very good actors.
Just a few of my thoughts on the issue:
The VA is now buying encryption software for theirÂ computers, handhelds, and other mobile devices.Â This makes me wonder about a few things:
Even though a risk analysis is always needed, the results are not always correct.Â Even if you go about the process in the most scientific manner, you always need to plan for contingencies and the possibilities that your results are either not right or the smallest risks will still happen.
In this case, if the VA did run a risk analysis before the thefts, then they either ignored this risk or deemed it not enough of a risk to worry about.Â Though we see it as an obvious risk, and though the many, many stories of laptop theft happening out there before the VA incident make it even more obvious, the VA still did nothing.Â That’s why I think they either never had the analysis done, or they simply did one to fulfill requirements then ignored the results.Â Both are deplorable practices.
I would really like to see some better disclosure from the VA.Â Don’t give me the results of your risk analysis.Â Just let us know that you are performing one.Â Just like this event, make an announcement that you have a company coming in to help with this and name the company.Â Even though you have an obvious hole with the laptops and desktops, you still need to perform your due diligence in making your security holisticÂ DoÂ not just piece some security measures together to make everything look good to the public.
Martin McKeay posted a few days back about keylogging software on client’s of HSBC Bank.Â Bruce Schneier pointed outÂ thisÂ article this morning about the same issue.Â Both came to roughly the same conclusion: this is ridiculous.
Yes, there are things the bank can do toÂ help with this, but come one, where is the personal responsibility for the clients?Â Sheesh.
Read the story here.Â It looks like the process is being held up now because of legal challenges from another company that thought they should win the project.
I have held out commenting on this so far because IÂ don’t have the expertise here to addÂ much of value.Â But what does concern me is that the company they are awarding the contract to is a an affiliate of a German-owned company.Â That sounds about as smart as giving up the dock security to an Saudi-owned company.
Like Mike Rothman says today, this has been the week of NAC, so I figure I would pile on as well.Â I am notÂ an expert on NAC by any means, so forgive me and correct me where I need it.Â But in talking to Alan Shimel and his StillSecure crewÂ this weekÂ and with all the bloggersÂ putting out some great information,Â I have learned more about NAC thisÂ week than I have in the last year.Â BTW,Â a bunch of my blogging buddies and Richard Stiennon got together last night on the Security Roundtable Podcast (hasn’t been posted yet) to discuss NAC, so I am really excited about listening when it gets posted.
Anyway, to my gripe of the day.Â Â I had a NAC vendor out today to discuss their product.Â They have gone totally with the inline strategy for their solution, andÂ it seems like a good product.Â But it has weaknesses (obviously everyone of them have strengths and weaknesses).Â Some of what I saw was poor ongoing posture checking, so-so unmanaged-client checking, opening of ports to allow authentication, and no remediation after quarantining.Â And they partner with other vendors to do some of the stuff above.Â That’s not in-and-of-itself a problem, but I just didn’t like the way they threw it all together.Â To be fair, they had one feature thatÂ I REALLY liked, and thatÂ was the ability to do auditing and reportingÂ on client file access without (so it seems) the need to turn on auditing on your servers (basically, they go to level 7 and report from there – if it works, it would be great to have because it means less CPU cycles, less disk space, and less configurationÂ on servers – anyone else do this guys?).
I have looked at a few other vendors out there as well, andÂ as I parenthetically said above, they all have weaknesses and strengths.Â Many times, it reallyÂ depends on your infrastructure and what you need.Â Â And it may take more than one vendor to get done what you need.Â Â Though management starts sucking bad, right now this may be the only choice we have to get a complete solution (go see Alan’s point in hisÂ post about cobbling together a bunch of security vendors for a NAC solution -Â I hope he is right that this will start going away).Â
As a quick aside, I am going toÂ compliment StillSecure, and it is not because Alan had me on his podcast (well, maybe a little bit).Â StillSecure’s Safe Access, thus far, seems to have the most complete solution out there (Alan, send the check to my personal address please).Â Now, back to our regularly scheduled program…
But one weakness or missing part or whatever you want to call it that I see across the board is the remediation of the vulnerabilities for the endpoint.Â What I mean by that is that I have not seen one of the NAC solutions that includes a remediation solution.Â They either partner with someone (which also seems to be going away somewhat), or they leave it up to the “discretion of the administrator.”Â So please answer this question for me, oh you Alan’s and Mitchell’s of the NAC world: wattup wit dat?
I mean, I just don’t get it.Â I am not speaking for the rest of the security managers out there, but I know that it just makes sense to me for someone who is going to offer quarantining to offer remediation as well.Â Is it because no one has made it that far?Â Is it because the market is not asking for it?Â Is it because there are options available, so you just don’t want to spend the dollars to do it?Â Â And if you are going to partner with someone for it, INTEGRATE IT.Â Don’t make me manage another solution.Â Tie the dang things together, and make it work.Â Remember my busy security manager post?Â We need help!Â Give us a solution that works from A to Z.Â Not A to W, then BigFix can handle X,Y, and Z (now I’ve said my ABC’s, next time won’t you…Â sorry, too much Sesame Street – I have small children).
[As I was writing this, I wanted to make sure I wasn't smoking crack, so I looked closer at SafeAccess and noticed that it mentions tying together patch management with SafeAccess, and I think this happens through VAM, but I am not sure.Â I invite Alan or another StillSecure employee to clarify this.]
Alan Shimel from StillSecureÂ was kind enough to have me as his featured guest on his podcast tonight.Â Alan is a great guy and a great blogger, and I am proud to call him one of my blogging buddies.
We were joined by Mitchell Ashley (a.k.a. Ed McMahon), the CTO of StillSecure, who seems like a great guy as well.Â He just started blogging, and you can find him at http://www.theconvergingnetwork.com/.Â
I just have to say that I had a great time tonight.Â The people over at StillSecure are a class act.Â As I mention in the podcast, I don’t get the usual line of BS from these guys.Â They tell you what is and what ain’t, and that is it.Â Nice people all around.
Thanks again to Alan and Mitchell.
Politics can be fun, and it can be real ugly, and often both at the same time.Â And in this digital age, everyone has a chance to get involved, including script kiddies that have a political axe to grind.Â Go read the story here.Â But what got me about this whole deal was this quote from Dan Geary, who runs Lieberman’s site:
“This is a direct disruption of a federal campaign,” he said.Â “I have to see us go to an era where security is primary instead of the primary focus being new and innovative ways to get the message out.”
Uhhh, that deserves a big “duh”.Â Dude, you run the website.Â I am sure you are an activist and want to get Senator Lieberman re-elected, but running the website and securing the website is your job.Â Frankly, that quote sounds more like something a politician would say rather than a web admin.Â If you don’t know that you are going to be dealing this kind of stuff, then the good senator hired the wrong guy.Â Sheesh.
…because you can read about it in the news, because it generally happens for the same reason (stupidity, mainly), and I get tired or writing about it.Â And the same would be the case on this new VA stolen desktopÂ (also read here), except that this is twice for the VA, and I think this one holds more importance.Â Why?Â Glad you asked!
I am going to try to make this short since Treasure Hunters is about to come one,Â so here goes.Â I posted yesterday on my Computerworld blog about some stuff I wrote for a friend of mine on two-factor authentication.Â I checked back today to see if I had any comments, and I did (woo hoo for me).Â I read the comment, and here is part of what I got:
What is needed is “smart” content that works with multiple trust levels, that self-authenticates not only the content but the user as well. This is done using a modified token inside the content. It also creates an audit trail within a token receipts for archiving.
Content-centric security allows content to be securely transferred globally and outside the enterprise, without centralized authority. No, there is no standard but this approach solves most, if not all, of today’s issues concerning authentication.
OK, this really gripes me.Â First off, there is so much of this “we need this” andÂ ”we need that” and it would be great if…” andÂ ”this would solve so many problems” that I am going to puke.Â I am just tired of hearing it.Â Yea, there are a lot of things out there that need to be done, but since when does a “need to be” turn into something tangible overnight?Â Not to mention the fact that this guy sounded like he was trying to sell something and then didn’t even link to a website or anything.
I am not arguing whether this guy is right or wrong.Â I am not arguing whether or not the state on InfoSec needs to change (it does).Â Basically, I just want people to be realistic and deal with what is available today.Â I am not asking for status quo.Â I just want people to recognize that us guys and gals in the trenches need to use products that are on the market now.Â If we were supra-geniuses that could make up new technology to protect our network while sleeping, then we would do it.Â But we aren’t and we can’t (I guess I should speak for myself).Â We rely on those people who research this stuff to do that.Â
So friggin’ stop arguing with me every time I say multi-factor authentication is a good idea!Â Â It is what we have today.Â Just because it can beÂ compromised in some fashion does not mean I should take it out of my network.Â Once again, DEFENSE-IN-DEPTH!!Â It is another layer.
I am not against research and looking for something new.Â I just am tired of being preached at about how something is better when it ain’t even sold by anyone yet!Â Sheesh.
I am going to combine my security tip of the day with my series of advice for security admins and managers.Â So here goes:
I can sum up this advice post in two words: due diligence.Â It is obvious that due diligence is necessary in all aspects of security and other areas, butÂ lets go over a few examples:
Practicing due diligence will make your network secure and your career successful.Â Getting a reputation for being anal can sometimes be a bad thing, but in security it is an endearing term.
I have mentioned Michael at mcwresearch.com couple of times on some of my posts, but I recently made the decision to add him to my blogroll (congrats Michael – I know you have just been waiting around with baited breath to get on my blogroll ).Â Â I must say that I am already a fan of Michael’s stuff.Â His writings are clean, concise, and very well thought out.Â His writing also varies nicely among different security topics.Â Specifically, he, Alan Shimel, and I have just started posting daily security tips for this week, and it was Michael’s idea to start it up.
Catch the feed.Â You will not be disappointed.
I am going to sponge off of Michael’s tipÂ at MCWResearch for my tip of the day.Â Michael gives some good advice for configuring and managing firewalls (Michael must be old-school security, since firewalls aren’t needed anymore – right….).
He specifically talks about egress filtering, which is something many companies doÂ not take use in their security.Â Michael talks about specifically blocking certain ports, but I think you should go a step further andÂ have default deny on all traffic incoming AND outgoing, then open ports as needed.Â It makes sense, but many people do not think outbound needs to be filtered.Â But as Michael pointed out, allowing IRC is inviting bots to start popping up on your network, and then the bots continue to report back to the IRC server.Â They establish the connection, so no inbound port needs to be open for the attack.
Additionally, IÂ suggestÂ Websense or something similiar to block specific protocol access (again, default deny and allow as needed).Â This can be another layer that can protect against web proxies and anonymizers and the like so your users can’t try to get around your firewall.