Ars Technica is running an article called Recycle Bin not enough, Microsoft adds ‘Previous Versions’ support on the file system level. Much like Windows XP and Windows Server 2003’s “Volume Shadow Copy” and “Previous Versions” capability, with one key difference (emphasis added):

With Windows Vista, the operating system will make “shadow” (that is, backup) copies of files and folders for users who have “System Protection” enabled (the default setting). The feature will be called Previous Versions, and will be accessible via the right-click properties menu as “Restore previous versions.”

Of course this is subject to change by the time Vista actually ships, but is it a good idea to have backups of every file stored on your system? To me this makes just one more argument for encrypting the whole disk.

Note: the backup information is not stored with the file—when you send someone a file you’re only sending that version, the backup is stored separately in the filesystem.

Data, laptops, etc. make headlines when they get stolen. Not good news for the companies that get heisted. Of course companies, governments and the like don’t want bad publicity. They hide or make excuses – implementing damage control as fast as possible.

Boy, do they sure feel good about themselves when that missing laptop with your social security number on it is found. Take this article for example.

A laptop computer containing personal information on more than half a million New York state workers has been found after it disappeared May 9 from the offices of a third-party data management company.

Excuse me, when did you say the laptop went missing? May 9th did you say? The point is that once data is gone, it is gone. You can’t get it back, and even if you find that missing laptop in a dumpster behind Starbucks, you have no idea what information was gathered, copied, sold, and to whom.

It may make people feel better, and companies look better, but these kinds of stories don’t usually mean much.

Stealing a laptop is not like stealing a bike, and recovering one isn’t the same either.

This past weekend, Slashdot posted a story entitled Why Popular Anti-Virus Apps ‘Don’t Work’. It references two articles containing discussions of the same.

Malware authors are writing code that will get around the signatures of the application by testing their code on the most popular anti-virus software before release.

Well, duh! I had a computer science professor that would give us an F if he could get our programs to crash. He always sat down and tried the same few things to start with—wrong parameters, corrupt input data, etc. If you didn’t test for these before you turned it in, you got the grade you deserved. If you wanted a virus to propagate, wouldn’t you test that it wasn’t detected by the popular AV (anti-virus) software first?

Anyway, in order for AV software to not slow your machine down to an unusable state, they rely on checking for “signatures” of the virus—typically expected chunks of code within an executable (either the code itself, a CRC checksum or hash of the same). Other methods exist, such as heuristic analysis and running everything in a sandbox, but they typically slow down the client too much.

Are signatures still really the best way to prevent the spread of computer viruses? What will the next generation of viruses and AV software hold?

I went with a group of five friends, meeting three more when we got to New York, but our adventure started before we even left DC. We were ticketed on a train to NY-Penn at 8:30 pm on Thursday. So we all planned on meeting at Union Station between 7:45 and 8pm. I was metroing with two others, and we got out of the metro, called the two we were meeting at the station, and I headed over to the ticket machine to pick up the tickets. I got our tickets, but then we noticed that the police had the gate area blocked off. We were eventually (over the course of about an hour and a half) evacuated to across the street from the station – leaving the “courtyard” empty as well. We weren’t originally told what was going on, then someone mentioned that there might be a bomb but seriously, no one wanted to go outside in the muggy heat. We attempted to entertain ourselves outside for a while (we were going to a hacker conference and had quite a bit of tech toys between us – including a police scanner, 2m radio, 2 DS Lites, cameras, cell phones and laptops), but eventually asked a police officer how much longer he thought it would be and we headed to the Capitol City Brewery for dinner and drinks. The humorous part is that one of my friends was planning on wearing a Bomb squad: If you see me running, try to catch up T-shirt. We finally made it onto the train at 11:30pm.

I was really disappointed in some of the speakers this year. Several were missing for various reasons (including Kevin Mitnick, who was “medically indisposed in Columbia” according to the announcement at the con). The quantum cryptography talk was cancelled, which was one of the big ones I wanted to see. I also hit up the “Proactively Secure Programming Techniques” by J. Salvatore Testa II, but I was really disappointed. The talk could be summed up by saying don’t use direct memory access languages, but if you have to use strn* and strl* functions. I was also disappointed with the “Password Cracking and Time-Memory Tradeoff” talk. This was given by Jason R. Davis of MD5lookup.com and was basically a talk about why you might want a terabyte sized database of all the MD5 hashes possible. Wasn’t this taught in school? I also hit up the Lockpicking talk which is always popular, and learning why having a post office box could be a bad idea.

There were a few talks that I wanted to get to but circumstances didn’t allow me to, including “Breaking Down the Web of Trust” and “Basics of Forensic Recovery”. I later heard that I probably wouldn’t have learned anything in them, but it still would have been neat to go.

The ones that were worth it were really good: “Wireless Security Flaws”, “Coupon Hacking”, and “Social Engineering”. Social Engineering is always fun. This year, Emmanuel Goldstein managed to get a woman with an unlisted address to give it to him by posing as a caller from the “Do Not Call” registry. He almost got a McDonald’s to turn of their A/C for a while (the victim said he’d try, and Emmanuel hung up after that).

If you ever have the opportunity to make it to a HOPE conference, I suggest you take it. It can be a lot of fun with a lot of learning.

Why do old systems lie around in the government and private sector, just waiting for Joe Hacker to come along? What about Jane, Sergey, and Wen Hacker too?

For most home users, it’s open the box and plug in the PC. Oh, yes forgot about those Mac commercials, but putting those aside, the OS we see is the OS we get. And the OS we get is often the one most users keep.

Of course, in the private sector and government you can’t just install or run machines, networks, or users in the absence of a policy framework. So systems are tested, then tested again, and so forth. The end result is usually a stamp of approval on one specific system, with a narrowly defined configuration.

A good thing because it provides everyone with a very predictable, reliable, and validated system. But what happens when a critical security patch is issued for an application or the OS? Installing the patch inherently changes the core of the system, and you are left with a system which is not the one before, and hence not validated. Validating various systems takes time, and as we all know, that translates into money. If you had to reassess a system every time a new Window patch was released, you’d never be able to test and approve a system before the next patch.

This leaves many systems out there in the government and otherwise, out of date, and vulnerable to attack. Many of these machines hold valuable data about you and I. Data about national security, financial information, and other goodies that many people would like to get their hands on. This leaves us in a tough spot; less security for more reliability. Applying the patches could cause disruptions to the system, create some unknown errors, or even introduce new security problems.

Some of these policies have clauses for security patches and some don’t. I think they should and here’s a simple way to test and apply the patches reducing any potential disruption to the system.

• An exact copy of a validated system should be available at all times.

• Critical application and OS patches should be given priority and tested on the copied validated systems. For most patches, through testing will not take much time at all.

• The patch should then be applied to the system(s) if they are proven not to cause problems in the system.

It may sound expensive or time consuming (or even obvious), but it doesn’t happen many times. Once data is stolen, it is gone forever and system that is taken offline by a script kiddie could cost millions. Testing and implementing work arounds is also costly, may lead to an overall less reliable system, and could make a system much more complicated than it needs to be.

Have you seen this situation? What are some of the methods you have seen to get patches and fixes installed on systems that are ‘policy configured’?

Came across this article via digg. A sad story is told how the “Director of Data Security And Compliance” was fired from his job due to incompetence after a break-in and theft left the company with hundreds of thousands in replacement and labor costs. The fired person’s story is that he tried to convince his management to implement all kinds of security controls that would have prevented this, but they chose not to due to cost.

Whether or not the story is true, a few lessons can probably be learned from it.

• If your job is to ensure your company is secure, and you’re recommending something that is absolutely required, don’t take “no” for an answer. Your job could end up on the line anyway, so you need to fight very hard against cost-cutting measures.


• Potential costs due to data/equipment theft or losses must be calculated before the loss occurs. This way they can be used as part of a return on investment argument for whether or not security improvements are implemented.


• Document all your requests and received responses having to do with requesting improvements in security. Send emails/memos instead of having verbal discussions. There’s a big difference between a guy telling a sad story about being wrongly fired, and a guy with documented proof who could sue his company for wrongful termination.

Until tonight, I hadn’t seen a mail client that didn’t support S/MIME out of the box (heck, even Outlook Express has limited support for it). Then I installed KUbuntu Dapper Drake on my laptop and discovered that KMail/Kontact indeed does not support S/MIME out of the box in this distro. I’ve got this setup screen asking me for all kinds of S/MIME Validation information (checking CRLs vs OCSP, etc), but it’s all greyed out.

It can be enabled but why should I have to do that? Now comes the fun of importing the 100 or so client certs I have for people into the system.

Some comments I have read indicate that KMail is not sure about using OpenSSL because of licensing issues – so use gnuTLS or libnss, both of which are workable replacements for the client side of openSSL (depending on what you’re doing).

Microsoft recently made some major changes to the Vista code to increase stability and create a more secure operating system.

This is the “new” Microsoft. More secure, stable, and able to do anything that (*cough*) Mac OS X can. To be honest, I like this shift and borrowing (to use the term lightly) provides the seeds for innovation.

To help improve security, MS is going to provide users with a product called Windows Live OneCare. It is a anti-virus/spyware scanner with some extra bells and whistles. (Windows already has a defragmenter, do I need repackaged it in this product??)

Here’s the catch. It’s $49.95 per year. Now don’t get me wrong, you have to pay for Symantec’s anti-virus too. But Symantec doesn’t write the OS code, they exist because MS can’t do it securely.

My point is why not just include OneCare with Vista? Users are paying (alot) of money already. Not only that, but home users will not pay for OneCare, because they don’t care. How many people do you know that just use whatever anti-virus that Dell preloaded on there, only to ignore expired definition update warnings after the free 6 months?

If OneCare is automated to update and scan automatically, then home users are covered. Less security problems gives you a better rep, and helps in dealing with the corporate market. I’d say, “just write better code,” but that isn’t going to happen.

Don’t play their game MS. Look from at other OSes you are already taking ideas from. How much money do you think Symantec makes from its OS X anti-virus scanner?

How much money do you think you’ll make from offering a product no one will pay for? How much more “secure” will that make Vista? The only way users will pay is with crashed hard drives, stolen data, and all sorts of headaches.

Here is an opportunity where MS goals meet consumer ones. MS wants to provide a more secure OS, “borrow” ideas, stifle competition (what company doesn’t deep down)...and ultimately generate more revenue. Let’s face it, the past few years haven’t been great for MS.

Incorporating OneCare meets these goals.

Users and businesses, want a secure OS too. A secure OS that takes care of itself, and doesn’t require mom and pop and the IT guy on the third floor to constantly be dealing with a varient of the Sober worm, and it would be nice that people wouldn’t be required to buy other anti-virus products to patch an expensive OS (hmm…lawsuit?)

Incorporating OneCare meets these goals too.

My car, I don’t know or care how it works. It gets from point A to B, and works for me. I take it to the shop and they tell me it needs a new dilithium crystal and shabam-kapow drive, so I just shrug my shoulders and have the mechanic install what they tell me.

But most of us know enough to get around. That big block is the engine, that smaller block is the battery, and so forth. I pop the hood and stare at it from time to time, and know just enough to be informed, but not cause damage.

Even better yet is that everything inside of the car is so dummied down so that practically anyone can drive an automatic transmission car, use the turn signals, or roll down the window.

We (yes, WE) in the industry need to make this shift too. In general, make applications, operating systems, and of course security, essentially dummy proof. The things that we encounter most (like turning on headlights, or starting the car, or in this context understanding SSL or security in general…) those things, simply NEED to be made as straightforward and stupid proof as possible. And I mean reeeally simple

The other stuff “under the hood,” like certificates and encryption algorithms and whatnot, can be dummied up a bit, so a casually interested user can kinda-sorta understand what the little lock, or AES means…and if a “pro” needs to examine other stuff, they can look deeper and be able to.

The current state of technology – take SSL for example – is like asking the average Joe to hotwire their car every time they want to start it.

What if, instead of a yellow “Maintenance Required” light, you got only the error code when something broke down or needed service – and could push a button to get rid of it?

You’ve got a problem with 4593052-OBX32, Click OK to continue, or “No” to stop in the middle of the road until you can research and figure out what is wrong. If you click “Ok,” you might break down and be carjacked or experience other problems, but clicking “Ok” does guarantee that you’ll keep driving.

What would you do?
Click

Put this post under the “rant” category, but other industries adapt to their customers, but we don’t so much.

I call it geekisistance, we all suffer from it to an extent, but why?

Digital signatures are not a new concept in the security world. The process is fairly simple: take some data, apply a hash algorithm to it, encrypt the hash with a private key, and then store the resulting signature somewhere. Assuming you don’t have to implement the cryptographic algorithms (which you shouldn’t), the process is very easy. So, why is it so hard to do over the web?

For one thing, most security libraries have made the problem too easy to tackle. Libraries such as CAPI for Windows, BouncyCastle for Java, and OpenSSL for C like to make creating digital signatures a one-function event. Pass in the data, certificate, key, and you get your PKCS7 signature block. This works great for desktop applications, but what about the web? What about the case where you have a big document on a server (like a PDF) to which you want a user to apply a digital signature? Adobe’s API for digital signatures provide no help here either – they’ll let you sign a PDF on the server, as long as the certificate and private key are on the server as well.

Obviously, you don’t want your users sending private keys to the server, and with pretty much all crypto devices, that’s impossible anyway. And, you don’t really want to have to send your giant file to the user, have him sign it, and then re-upload the giant file back to the server. I’ve recently worked on a project that attacks this problem. The idea is that the server takes the document and hashes it, sends just the hash to the client (less than 1K of data as opposed to a 10mb PDF), and the client applies his key to the hash and sends back the signature data, which the server then inserts into the document file. This required bypassing all of the convenience methods implemented in the server-side Java libraries and manually hashing the document and constructing the ASN structure for PKCS7 signed data from scratch. On the client side, it also required developing a custom ActiveX control because CAPICOM doesn’t support encryptring a raw chunk of data without turning it into a PKCS7 enveloped data structure.

This approach isn’t without its drawbacks, however. Such as, how can the client trust that the hash you sent is really the hash of the document he’s looking at? It does place a burden on the user to trust the application to “do the right thing”, but then again, the user has to trust desktop applications to “do the right thing” too. Issues of trust are also directly proportional to the importance of the application – i.e., do you really need ironclad authentication to sign a timesheet or a project status report? It isn’t an especially difficult technical problem to tackle for library developers…so why don’t crypto libraries make it easy to do, and then let company policy makers decide if and when it should be used?