Photo credit pedrosimoes7
I’m bookmarking a couple more videos to watch.
First, Defcon released their teaser set of videos from this year’s con, including Adam Savage’s “Failure”.
Second, I saw a link to Marcus Ranum talking at TEDx MidAtlantic.
http://tedxmidatlantic.com/live/#MarcusRanum
I had the opportunity to watch the first few minutes of the stream of Marcus Ranum’s talk at DojoCon 2009 but then had to go to a client site. I was happy to see they posted the videos to UStream so I can go back and watch the rest.
Among those who spoke:
In case you want to catch up too:
In late October, Microsoft released a software patch to address a problem in Windows operating systems. Every month Microsoft releases new software patches on the second Tuesday of the month, aka Patch Tuesday. For most companies Patch Tuesday is followed by Reboot Wednesday which is when the most important of these updates are installed and systems rebooted. In larger companies, Patch Tuesday is the beginning of a process to prioritize, test, and stage these updates as needed.
So what’s the big deal about October? Microsoft released an out-of-cycle patch (MS08-067) for Windows on October 23rd, nine days after Patch Tuesday. Typically patches are queued up until the next second Tuesday, but this one was so important that Microsoft released it immediately. The urgency about this patch was directly related to the potential damage that could be caused by the flaw it fixes. In theory the flaw could be exploited by a worm that would blow through networks like wildfire, causing severe damage along the way.
To be fair, Microsoft’s mistake was the flaw in Windows; their handling of the situation has been very good.
How can you benefit from this? It’s now over a month past the release of this patch, and it’s time to look at how your business handled the situation. You can use this event as one method to evaluate your overall IT posture. If you are in management, this may require digging in with the technical folks to get the details. Specifically, look at the following areas:
Take a look at how your business responded. Use this opportunity to identify any shortcomings and work to fix them. Oh, and if you look around and see that this was handled well, give your IT people the credit they deserve.
As you may well know by now, Apple recently decided that they would “leverage” their existing client base to their advantage. If you didn’t know, check Martin McKeay’s post about this. If you are running Apple’s software updater, they decided you need to bloat your system some more by installing Safari, whether you want to use it or not. Now if you’ve consumed the Apple Kool-Aid, you might not mind, and that’s your business.
I do have a big problem with this though. A vendor using an update conduit to install new software is just plain wrong. As network and security professionals, we generally preach the need to keep systems up-to-date. Generally we endorse the need to run update conduits and keep patches current. It becomes much harder to endorse this though when a vendor expands the updater outside of updates. There’s a bit of a paradox here. On the one hand, if you have something like QuickTime that seems to frequently hang in the vulnerability wind, you probably want to stay current with patches. On the other hand, if that patching process injects new software onto your system and therefore increases your potential attack surface area, you really don’t want to run that patching process. Hmmmm….
Now in the Microsoft world, I generally deal with this kind of thing on the corporate network by using WSUS. With WSUS, you can act as the informed filter for your users. If something comes down from Redmond that you don’t like, simply don’t approve it. I like that kind of control. Is there something similar for Apple updates? I don’t know, but you can bet this will lead to some checking into it.
What do you think? Is this abusive by Apple? Does this set a bad precedent? Is this a harbinger of Armageddon? (Just checking if you’re still awake.)
I just saw a link in a discussion at the Security Catalyst (thread is here) where Rebecca Harold pointed out the INFOSEC Year in Review compiled by Dr. Mich Kabay.
The project’s page is at http://www2.norwich.edu/mkabay/iyir/index.htm.
Last year’s report can be downloaded in PDF form from here: http://www2.norwich.edu/mkabay/iyir/2005.pdf.
At 525 pages, it’s not short reading, but even just a quick scan shows a wealth of useful information.
This was the first nugget that caught my eye. It’s dedicated to the paranoia in each of us:
KEYBOARD NOISE ALLOWS INFERENCE ABOUT WHAT’S BEING TYPED
Using sophisticated artificial intelligence programs, scientists from UC Berkeley have been able to deduce what people are typing simply from the sounds of the different keys. Doug Tygar and colleagues say that they don’t need to study the individual keyboard — the programs use the differences in sounds of keys on the outer side of the keyboard vs the sounds of the inside keys. The microphones can be outside the room being monitored. Over time, the software gets better, and “Once our algorithm has ten minutes’ worth of typed English, it can recover arbitrary text, such as passwords,” says Tygar.
Gotta love it.
Here’s a linear expansion of three articles that caught my interest: The first from Andy, ITGuy (Did complacency kill the cat or was the cat already wounded) refers to a post from The Daily Incite (Complacency killed the cat) which comments on a Small Biz Resource article (Report: SMBs Overconfident on Security).
I’ve worked inside small business, then enterprises, then consultant to large enterprise, and now consultant to SMBs. Frankly I prefer to work with small clients most of the time, but one of the big challenges is education. A large part of my job is educating the client so that we can then implement. It’s both a pleasure and a pain to do.
So, what’s education got to do with it? In many cases I think the complacency that’s being seen is really coming from ignorance. If a business owner / manager clearly understands the gravity of a situation they will be less likely to see roses everywhere they look. If, like most small businesses I’ve worked with, their #1 concern is just keeping it running, they feel success when they reach a state of system or network maintenance. When those same folks learn enough to understand the types, severity, and frequency of threats they face, they will be more likely to engage and work to improve their security. With that understanding, a simple firewall and AV deployment will turn from being seen as Fort Knox to my kids’ pillow fort.
Part of network security is to cover all the bases, including the software used to run your business. Your network can have every security measure known to man, but if your software has holes, you’re sunk.
The base two categories to look at are internal and external threats. Internal threats are employees that are looking to steal your contacts/data. External threats could be a fired employee, a virus, a hacker, or some bored 15 year old latch key script kiddie.
Internal threats are handled by designating roles. To help illustrate, let’s look at an object oriented design called “document/view”. The document holds the raw data, and the view reveals a portion of the data. For example, a salesperson view would hold the data for one customer, with their invoices and payment history. A sales manager view would group the raw data into a quarterly sales report. Each view corresponds to a role.
Traditionally, applications would denote the roles as “Salesperson” and “Sales Manager”. However, that doesn’t fit well for small and medium businesses. I prefer a more granular approach. You could still have the salesperson role, but the quarterly sales report would actually be “Quarterly Sales Report”. This allows you to give that role to the top 3 salespeople that have been with you for years (and more than likely are related to you).
External threats can be physical or virtual. Physical access is obvious to address (deadbolts, pit bull with aids, etc). Virtual access is more tricky. A few pointers:
Cleanse any data coming directly from a shopping cart, registration page, or other external source.
Don’t have one login/password to login to the system. Have a password maintenance policy.
Review your logs.
Use anti-virus/email filtering service.
Develop a data retention policy.
Make sure your data backup is secure.
Finally, use software that conforms to your business. If software changes your roles, it could lead to employees having data you’d rather not reveal. After all, it’s your business.
In Alex Bakman’s recent post he says “It’s time to let your actions show just how committed you really are to securing your infrastructure”.
Time to come clean… I can’t remember not using my current “strong” password, and my online passwords wouldn’t be considered very strong!
Charles and I are quick to tell people that security is not convenient. Well, it’s time for me to be inconvenienced and develop some new strong passwords, put them to use, and devise a password changing policy for myself.
If you don’t know, the coming change in the start of daylight savings time (DST) may pose quite a problem for some. Because the date of the change has moved up by four weeks this year, Windows doesn’t know the correct date to shift without patching. Microsoft has released a patch for Windows 2003 and Windows XP, but there is no public patch for Windows 2000 because it has passed the end of its support life.
Now, what does this mean for YOU?
Well, if you deploy no patches to any systems, it means things will work but that for four weeks your clocks will be off by an hour. Sort of a pain, but not a show stopper.
What if you do deploy patches but may not be reliably reaching 100% of your systems? That is a problem. If you are like some small businesses I deal with, the servers are updated regularly (if not immediately), but the clients may or may not be. In this scenario, your servers will shift DST on March 11th like they should. Any unpatched workstations will not shift, and those stations will not be able to login to an Active Directory domain because of the embedded time stamps in Kerberos authentication. Uh oh. Problem. This is further compounded by the fact that there is no official Microsoft update for Windows 2000.
So, what are you to do? Here are some thoughts on how to handle this:
I spent a few minutes of research and a few more of script development and have gotten what should be a working solution for patching Windows 2000 (and XP too). Now bear in mind the standard disclaimers: This is barely tested code. Your mileage may vary. Actual use of this code may cause abdominal pains and other unpleasant side effects. In other words, like any code you get off the internet, test the snot out of this before using it. That being said, this solution has both a .reg registry file and a .vbs script for deployment. This is specific to the Eastern time zone, although it would be trivial to change the one registry entry to apply to a different time zone.
Here is the .reg file contents:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Eastern Standard Time]
“TZI”=hex:2c,01,00,00,00,00,00,00,c4,ff,ff,ff,00,00,0b,00,00,00,01,00,02,00,00,\
00,00,00,00,00,00,00,03,00,00,00,02,00,02,00,00,00,00,00,00,00[HKEY_LOCAL_MACHINE\SOFTWARE\ServerGuys\Patches\DST2007]
@=”True”[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
“StandardStart”=hex:00,00,0b,00,01,00,02,00,00,00,00,00,00,00,00,00
“DaylightStart”=hex:00,00,03,00,02,00,02,00,00,00,00,00,00,00,00,00
As with any .reg file you could deploy this in a number of ways. One of my favorite ways to reach out and touch my clients is via a login script. Here is a script that will deploy this patch. Two notes: Obviously you don’t need the HKLM\Software\ServerGuys key in the .reg file for the DST patch; it’s used in the following code. Also, I know this is poor code, but it was quick to write and seems to work.
‘=============================
‘ Domain Login.vbs
‘=============================
On Error Resume Next‘Get a reference to the WSH Network object
set WSHNetwork = CreateObject(“WScript.Network”)‘Get a reference to the WSH Shell object
set WSHShell = CreateObject(“WScript.Shell”)‘Windows DST 2007 Patch
‘======================
if fn_RegKeyExists(“HKLM\Software\SII\Patches\DST2007″) then
if WshShell.RegRead(“HKLM\Software\SII\Patches\DST2007\”) <> “True” then
WSHShell.Run “regedit /s \\SERVER\SHARE\DST-2007.reg”
end if
else
WSHShell.Run “regedit /s \\SERVER\SHARE\DST-2007.reg”
end if‘=============================
‘ Functions
‘=============================
Function fn_RegKeyExists(ByVal sRegKey)
fn_RegKeyExists = True
sRegKey = Trim (sRegKey)
If Not Right(sRegKey, 1) = “\” Then
sRegKey = sRegKey & “\”
End IfOn Error Resume Next
WSHShell.RegRead “HKEYNotAKey\”
sDescription = Replace(Err.Description, “HKEYNotAKey\”, “”)Err.Clear
WSHShell.RegRead sRegKey
fn_RegKeyExists = sDescription <> Replace(Err.Description, sRegKey, “”)
On Error Goto 0
End Function
This script is just a slicing out of the relevant pieces from a rather large login script I use, but it should point you in the right direction.
See a problem? Have a beef? Feeling abdominal pains? Shoot me an email and tell me what you think: charles@serverguys.com.
Datasecurity from PCI and Data Security Compliance was kind enough to both comment on my PCI thoughts from yesterday and pen an entry of his (her?) own. Apparently though I must not have been clear in my thoughts.
Datasecurity replied
I’m sorry to hear you feel that PCI is a tough pill to swallow.
To be accurate, I personally think PCI can have great impact in numerous ways. My question is pointedly about small business owners who may find the controls and changes needed for compliance to be a rather bitter pill.
Also Datasecurity stated
This is true, but why should a small or medium sized company be permitted to put my credit card data at risk just so they can reduce costs?
Of course no one is advocating reckless abandon with your personal credit card data. This paints a rather negative picture of those with whom you choose to do business. I think instead that for many small merchants compliance is an issue of control. Personally, as a network weenie I like the controls that compliance must introduce. Compliance encourages a more complete approach to security and processes. I like that. But what I would like to hear are how people have successfully (or not-so-successfully) introduced these controls and measures within small merchants.
Compliance for compliance sake is a good thing, but I would like to find strategies to convey that compliance can have so much more value. How can we help small merchants find the silver lining of compliance and begin to view it as a benefit rather than a burden?