More often than not, we consider a new security control, whether it be a firewall upgrade, host intrusion software deployment, or Identity Management solution and fail to ask ourselves:
Why are we doing this?
What's the goal of putting this security control in place?
Are there any risks associated?
What is the expected outcome?
Is the way we're deploying this technology, the "best" that we can do? (Without impacting business efficiency of course.)
I know it's simple in nature, but seriously, asking those questions is where the real securitah lies.
Tuesday, May 20, 2008
Wednesday, February 27, 2008
Know your fundamentals. Period.
"I want to get into a security role within IT."
My advice? Know your fundamentals. Know the core of what makes the world go round in systems, software, or networking technology.
Now please, don't start with the "C'mon dude, are you serious?" after reading this list. Let me esplain. No, there is too much, lemme sum up.
- Understand DNS, in and out. It's been around since the beginning of time.
- Understand TCP/IP, TCP flags & communication, and packets (at least at a level that you can use Wireshark or tcpdump.) I'm not talking about decoding packets in hex and chewing gum at the same time.
- Learn how to administer and troubleshoot issues with Windows Server, and pick-your-flavor of UNIX/Linux. Start small. Think performance monitoring, network monitoring, and service monitoring tools for each platform.
- Understand dynamic routing and networking topology protocols. Spanning-tree and BGP can get very deep – at least know how they function, and primary causes for them to not function properly.
- Learn what viruses, Trojans, and rootkits are, at a high level. Know how some of the primary penetration and propagation techniques occur.
There are a lot more. I know. But I'm more and more surprised by how many technology professionals do not understand core fundamentals like DNS. Or how to break down a TCP traffic flow between two hosts.
Let's not forget this fact: you'll become a stronger security professional by being a great systems/software/networking professional first.
Respect the securitah by knowing and applying your base skills.
Thursday, February 7, 2008
WSUS, 2/12, IE7 for all! Joy and merriment!
For those that didn't see the diary posting at the Internet Storm Center yesterday/today:
"On February 12, 2008 Microsoft will release the Windows Internet Explorer 7 Installation and Availability update to Windows Server Update Services (WSUS). Windows Internet Explorer 7 Installation and Availability Update is a complete installation package that will upgrade machines running Internet Explorer 6 to Windows Internet Explorer 7. Customers who have configured WSUS to "auto-approve" Update Rollup packages will automatically upgrade machines running Internet Explorer 6 to Windows Internet Explorer 7 after February 12, 2008 and consequently, may want to read Knowledge Base article 946202 to manage how and when this update is installed. For more on the Windows Internet Explorer 7 Installation and Availability Update, read Knowledge Base article 940767."
Moral of the story:
As much as Microsoft wants to extend their QA department into your corporation, don't let them. I'm not a fan of any "auto-updating" service. True, most of the time, everything will work out just peachy, you'll be patched/updated/band-aided/snug-as-a-remedied-software-bug-in-a-rug....BUT....there's always the chance that the new shiny update will PUNCH YOU IN THE FACE.
So, test, test, test.
And if you're screaming at me - "We don't have the money for a test environment!" - there are virtual PC/server options. And they're free. And they work.
I'm pretty sure Matt Neely over at Security Second Thoughts knows a thing or two about virtualization. And believe me, he definitely knows three or four things about mobile commerce...
On another note...I'll be adding a section that shows the security blogs I like reading. I'll keep it limited to 10 - a lot of them tend to repeat what others are saying.
Thursday, December 20, 2007
InfoSec Policy - why not?
Policy.
Ugh.
Most people in the IT field dread anything that relates to documenting "how" to do something related to their positions. Why should we? It's all up here (point to your forehead - i.e. the steel trap).
I'll be honest. Documentation isn't my FAVORITE thing to do. But then again, neither is working, period. So why am I writing about infosec policy? Because time and time again, we come up short; whether that means our infosec policies don't exist at all, or they cover only "Acceptable Internet Use", or they're:
First opinion: we get lost in thoughts of the policy having to cover everything. That's like saying, "I don't want to create any laws because I want to make sure that no one commits any crime." Not possible! But wouldn't we be better off having 5 laws versus no laws? Don't murder, don't steal, don't lie, don't litter, and don't be a jerk. I would think the world would be a better place having those 5 laws versus NO laws whatsoever. Same goes with an infosec policy. You might as well get started now, because anything you outline and document is better than nothing at all.
What does policy mean? "A definite course of action adopted for the sake of expediency, facility, etc."
How do I define it? It's a blueprint. Plain and simple. You wouldn't build a house without a plan, right? Why would you build a holistic security strategy without a plan on what you're going to do, how you're going to do it, who will be responsible for which parts, etc. It's that simple. Seriously.
But wait, here comes the second opinion. Blueprints are big. REALLY big! Not necessarily, my peoples. They're a guide. The blueprint doesn't have to be the SIZE of the actual house. Neither does your infosec policy. I was at a security seminar a few years ago, and the guy (can't remember his name) asked the audience if their companies had an information security policy. 25% of the audience raised their hand. Then he asked how big the policies were and what they covered. I'll never forget this dude from IBM raising his hand and telling everyone that their infosec policy was 5,000 pages long.
C'mon, seriously. Whoever or whatever team wrote that pile of crap obviously liked to hear themselves type or were a bunch of reefer addicts. I would take that thing out into a parking lot and light it on fire, and then start over with something that someone WOULD ACTUALLY WANT TO READ.
Isn't that the point? For people to read it, understand it, and follow it's direction?
So my goal, and what I was taught, is that it should be clear, concise, and written at a 7th grade reading level. I shouldn't have to bust out the dub-dub-dub dictionary.com in order to understand what I'm being held accountable for. Right? Thanks for agreeing...
What is the point of this post? Start working on something now. And don't do it because HIPAA, SOX, or PCI made you. Do it because you need and want to do the best thing for the positioning of your security posture. Stop talking about it. Stop saying, "We don't have an information security policy." Start doing.
A general information security policy could start by putting together a quick one or two page outline of how the organization takes security seriously, and it's goals. Then start on the sub-policies that actually define specific areas.
What are sub-policies?
If we just start doing, instead of talking, we can all get through this process. We have to. Every solid security organization depends on it. I promise.
Respect it.
Ugh.
Most people in the IT field dread anything that relates to documenting "how" to do something related to their positions. Why should we? It's all up here (point to your forehead - i.e. the steel trap).
I'll be honest. Documentation isn't my FAVORITE thing to do. But then again, neither is working, period. So why am I writing about infosec policy? Because time and time again, we come up short; whether that means our infosec policies don't exist at all, or they cover only "Acceptable Internet Use", or they're:
- Super long
- Super hard to read
- A super waste of paper and hard drive space
First opinion: we get lost in thoughts of the policy having to cover everything. That's like saying, "I don't want to create any laws because I want to make sure that no one commits any crime." Not possible! But wouldn't we be better off having 5 laws versus no laws? Don't murder, don't steal, don't lie, don't litter, and don't be a jerk. I would think the world would be a better place having those 5 laws versus NO laws whatsoever. Same goes with an infosec policy. You might as well get started now, because anything you outline and document is better than nothing at all.
What does policy mean? "A definite course of action adopted for the sake of expediency, facility, etc."
How do I define it? It's a blueprint. Plain and simple. You wouldn't build a house without a plan, right? Why would you build a holistic security strategy without a plan on what you're going to do, how you're going to do it, who will be responsible for which parts, etc. It's that simple. Seriously.
But wait, here comes the second opinion. Blueprints are big. REALLY big! Not necessarily, my peoples. They're a guide. The blueprint doesn't have to be the SIZE of the actual house. Neither does your infosec policy. I was at a security seminar a few years ago, and the guy (can't remember his name) asked the audience if their companies had an information security policy. 25% of the audience raised their hand. Then he asked how big the policies were and what they covered. I'll never forget this dude from IBM raising his hand and telling everyone that their infosec policy was 5,000 pages long.
C'mon, seriously. Whoever or whatever team wrote that pile of crap obviously liked to hear themselves type or were a bunch of reefer addicts. I would take that thing out into a parking lot and light it on fire, and then start over with something that someone WOULD ACTUALLY WANT TO READ.
Isn't that the point? For people to read it, understand it, and follow it's direction?
So my goal, and what I was taught, is that it should be clear, concise, and written at a 7th grade reading level. I shouldn't have to bust out the dub-dub-dub dictionary.com in order to understand what I'm being held accountable for. Right? Thanks for agreeing...
What is the point of this post? Start working on something now. And don't do it because HIPAA, SOX, or PCI made you. Do it because you need and want to do the best thing for the positioning of your security posture. Stop talking about it. Stop saying, "We don't have an information security policy." Start doing.
A general information security policy could start by putting together a quick one or two page outline of how the organization takes security seriously, and it's goals. Then start on the sub-policies that actually define specific areas.
What are sub-policies?
- How do you administer changes to the firewall? Who approves the changes? Now you have a Firewall Administration policy.
- What can I do with my computer? Am I allowed to hack Switzerland? Now you have an Acceptable Computer Use policy.
- Do you have third-party organizations connecting to your WAN/LAN? How should they connect? Now you have a Third-Party Communications policy.
- Am I allowed to use a signature including my e-mail address, phone number, title, and address when I post to my favorite tech forum? Now you have an Information Dissemination policy.
If we just start doing, instead of talking, we can all get through this process. We have to. Every solid security organization depends on it. I promise.
Respect it.
Monday, November 12, 2007
Knoppix-NSM
Just downloaded Knoppix-NSM, a bootable Debian .iso for network security monitoring. I saw an article about it in the October issue of Information Security Magazine. Includes stuff like Snort, Sguil, BASE, etc. Very clean and trimmed down from what I've seen so far. I'm going through the HDD install right now, and will soon throw it on my home network.
I'll update the masses.
I know you're out there.
I'll update the masses.
I know you're out there.
Tuesday, October 30, 2007
Microsoft IAS & PEAP. What fun...
I started deploying my first large(r) Microsoft Internet Authentication Service implementation at a client a couple weeks ago, and it's been a work in progress. At first, the client was using RADIUS as a second set of authentication for their remote VPN client connections. After their wireless security was tested (and rated poorly), they decided to go with a PEAP/WPA2 auth/encryption architecture. Sounds good! Unbelievably, Microsoft has an entire certificate solution laid out for this sort of thing, with Verisign. Stop the world!
All in all, it's working out well. There's roughly 70 devices using AAA now; I have a primary IAS box, with a secondary IAS box for redundancy at the same physical site. I wish IAS config was replicated automatically, but the manual process is pretty easy. And what's with IAS proxies? WHEN DO YOU ACTUALLY NEED TO USE THEM? Are there any benchmarks to go off of?
The one area I found to be challenging was the creating specific profiles with the Remote Access Policies. Getting the right attributes as "match" criteria within the policies, AND putting the policies in the correct order for application can be difficult. Lots of trial and error. Unfortunately there isn't a ton of documentation out there on the subject, especially if you want to use the same IAS box to authenticate wireless users, VPN users, and network administrators gaining access to LAN/WAN hardware.
George Ou from TechRepublic posted his "Ultimate Guide to to Enterprise Wireless LAN Security" earlier this year, and there are a number of step-by-step guides on deploying PEAP using MS IAS as the RADIUS server. I don't know about you, but using the word "Ultimate" in a title of anything info/net sec related just makes me sweaty. Seriously, "Ultimate"? Maybe if Joshua Wright wrote it. Then again, "ultimate" is a strong word in our field.
PEAP w/ MS-CHAPv2. Secure? Sure. Most secure? Obviously not. But, if a weak password policy was a problem before implementing a wireless PEAP auth strategy, it'll always be a problem.
So there you go. My first post. Don't hate! Respect it.
All in all, it's working out well. There's roughly 70 devices using AAA now; I have a primary IAS box, with a secondary IAS box for redundancy at the same physical site. I wish IAS config was replicated automatically, but the manual process is pretty easy. And what's with IAS proxies? WHEN DO YOU ACTUALLY NEED TO USE THEM? Are there any benchmarks to go off of?
The one area I found to be challenging was the creating specific profiles with the Remote Access Policies. Getting the right attributes as "match" criteria within the policies, AND putting the policies in the correct order for application can be difficult. Lots of trial and error. Unfortunately there isn't a ton of documentation out there on the subject, especially if you want to use the same IAS box to authenticate wireless users, VPN users, and network administrators gaining access to LAN/WAN hardware.
George Ou from TechRepublic posted his "Ultimate Guide to to Enterprise Wireless LAN Security" earlier this year, and there are a number of step-by-step guides on deploying PEAP using MS IAS as the RADIUS server. I don't know about you, but using the word "Ultimate" in a title of anything info/net sec related just makes me sweaty. Seriously, "Ultimate"? Maybe if Joshua Wright wrote it. Then again, "ultimate" is a strong word in our field.
PEAP w/ MS-CHAPv2. Secure? Sure. Most secure? Obviously not. But, if a weak password policy was a problem before implementing a wireless PEAP auth strategy, it'll always be a problem.
So there you go. My first post. Don't hate! Respect it.
Subscribe to:
Posts (Atom)
