Password management for shared passwords

How do you in your company or organization store passwords that are shared among staff or teams? I hope you do not use an unencrypted spreadsheet located on a network share in a folder named Passwords.

Most probably use a password manager application such as Keepass and even though it is open source (which I like) and sounds very good, it has weaknesses. Even though it uses AES 256 bit encryption, the encryption is no good if the passphrase is chosen poorly. This is not a flaw of just Keepass, but any password manager software. Second, even if the passphrase is very good, it can still be defeated by a key-logger which sniffs the passphrase. So, no real joy.

Many password managers also comes with browser extensions for easy fill in the password functionality when browsing the web. This has been proven to be quite a bad idea as all it took was some javascript to defeat this. Kevin Mitnick and Dave Kennedy showed a demo of this at Derbycon, see this youtube video.

But the problem is still there, how do you share passwords in a secure manner? The storage of the passwords needs to be encrypted or secured in a physical way to prevent unauthorized access. But it also needs to be available for the people who require them. There in lies the problem, and it is a very difficult problem.

I have no real answer to this question, but there are things you can do that will slow an attacker down. Use a standalone network which cant be accessed from the Internet, actually it should only be accessible from a secure physical location. Do that, and the attacker will have to go to great lengths to retrieve data. It is when we get sloppy and just save our passwords in plain text on a network share that the attackers get that easy win. Do not make it that easy, make the extra effort and stay safe.

How is your security awareness training?

You read about new threats every day. New malware are being discovered, new exploits are being developed and your security is constantly under attack. Sometimes it does seem futile, but there is one key factor to consider if you are going to stay safe or not. That key factor is your users as they can be your best friend or your worst enemy from a security perspective.

As attacks become more and more advanced, your technical security solutions will not be able to keep up. Hackers are almost every time at least once and probably a few steps ahead of you, no matter how hard you try to stay current. So, by showing your users how to stay safe, you can probably shift the outcome of the battle a bit. This is because a lot of the attacks today involve user interaction, they need the user to do something. Whether it is clicking a link or plugging in a USB stick they found in the parking lot, their action might make all the difference. If your users see a stranger lurking around, do they care or not? Do they care if a person tailgates? Do they know not to assume that all emails come with good intentions? Do they pick up that USB stick and plug it in or not? Do they act without thinking because they trust all that security technology that you as the security administrator has implemented? If they do, then you have missed something, that being to train your users to remain vigilant.

It does not really matter what kind of company or organization you work for, security awareness training is important. The only problem is that most security awareness training I have witnessed is plain stupid and misleading, even trying to strike a bit of fear into users if they do something wrong. The last bit really annoyed me, as you need your users to trust you, not fear you. It is OK do do something wrong, but I want them to come forward with it. Then you have a chance to correct it, otherwise you are in the dark.

Security awareness training is something that I think should be taught live, not using elearning where users simply read a slide and answer a question, then another slide and another question. It does not provide the kind of feedback as a live meeting with an ongoing discussion can provide. Also, when listening to and interacting with a person one can really see users reactions to different statements and discussed topics. Provide examples and perhaps demonstrate a hacking tool or two just to let them see how it is done in the real world. In my opinion, nothing beats a live show, and I think we can all agree that security awareness is very much needed, so why not aim to make security awareness training an awesome event. I know I intend do.

Problems migrating from Windows XP to Windows 7 using MDT 2013 and ADK 8.1

Are you using MDT 2013 with ADK 8.1 to try and migrate Windows XP to Windows 7? Then chances are that you have experienced a problem with the bootsect program or the presence of the bootmgr file.

The bootmgr file in C:\ should not exist on Windows XP, and MDT will try to use it if it exists. MDT creates this file once you try to deploy your MDT task sequence and thats OK, but it should not exist prior to running your MDT task sequence.

Second, the bootsect program used from ADK 8.1 and is located in your deployment share folder under tools\<architecture>\ can produce the wonderful error message on your Windows XP machine, which says it is not a valid Win32 application. Unfortunately, this is true, and Windows XP will therefor be unable to use it to set the boot sector on the machine you wish to deploy to boot using your Windows PE installation in MDT.

The only solution I have found for this error is to the use the bootsect program from the Windows ADK version 8 instead of 8.1. Install the PE environment and Deployment tools from version 8 (on a separate machine from your MDT host) and extract the bootsect programs for both x86 and x64, and replace your 8.1 versions 8(on your MDT host) with the ones from version 8. Do backup the 8.1 bootsect programs first though.

If you simply want to test it, replace the bootsect programs in your deployment share under tools\<architecture>\ and try your task sequence again. The reason for replacing the files in the ADK 8.1 install directory is because MDT will use those bootsect programs every time you update (regenerate) your deployment share. If you have not replaced the files, it will use the 8.1 version and your task sequence will once again fail.

Some mention different using Windows PE versions, but for me it works with version 5 from HP, since I deploy HP machines.

Happy deploying!