The State of Encryption

I just finished reading an article from a magazine that the big boys read. It had the results of their survey on the adoption of encryption. Bad news. Users want quick access to their data. So any encryption strategies rolled out to the enterprise get done one piece at a time. Well that might be good news if you are trying to break in.

One related technology that seems to have taken hold is tokenization. A user has a credit card number that needs to be protected. So a system will instead use a token for the duration of the session. The token is a 64-bit number that is used in lieu of the credit card number.

So what are some other factors inhibiting the adoption of encryption? There is no clear standard for systems to work with each other. The Oasis group is working on KMIP (Key Management Interoperability Protocol). And the IEE is pitching P1619. The authors of the article I read were hopefully that Microsoft would lead the way with their Active Directory. Good luck with that.

Security in the Cloud

A big city just hired Google to do their email. They put a lot of security requirements in their requisition:

• employees had to be fingerprinted
• all data sent must be encrypted
• data sitting around needed sharding
• access to data had to be limited

It is difficult to convince a customer that the cloud is secure. The technology is relatively new. There are no standards. The act of adding encryption slows things down.

You know the hackers are going to want to target cloud repositories. There is potentially a lot of corporate data out there waiting to be stolen. I do not know enough about Cloud Computing to determine whether the thing is secure enough for my trust.

PKCS Continued

A few posts back I started to talk about PKCS. Well let's finish the discussion. PKCS #9 defines attributes which apply to extended certificates, envelopes, and private key encryption. In other words, it defines details for PKCS #6, #7, and #8.

PKCS #10 defines the syntax or format of a request to a certificate authority. PKCS #11 is Cryptoki (crypto key). This is a hardware solution like using smart cards for authentication.

PKCS #12 defines how users can share private keys. PKCS #13 is the advanced topic of elliptical curves. I am not an expert in the technology. From a distance it looks like a lot of math.

PKCS #14 defines a pseudo random number generator. Generating true random numbers is difficult. Finally PKCS #15 covers tokens. That is PKCS in a nutshell. Although it goes up to PKCS #15, there are only 13 distinct parts as #2 and #4 are rolled into the standard for PKCS #1.

Next time I plan to get deep into keys. Stay tuned.

Time Bomb Scripts

Last month a contractor was fired from Fannie Mae. The reason for termination was promoting scripts to Production without authorization. There were a lot of mistakes made on the part of the company. They did not change the root passwords to the systems this contractor had access to. They also let him stick around after they fired him. This is bad news, especially given that the guy was let go for unauthorized code deployment.

What I found very interesting were the details of a bunch of time activated scripts this guy left behind at Fannie Mae. His first act was to add some code to the end of a daily script. This code would retrieve and install a bunch of other scripts.

Here is an example of what of the payload scripts did. It would generate a list of servers in the company. Then it would disable monitoring. Finally it would disable the ability to log into all the servers that it found. Well that is bad, but is not too evil.

Next the terminated contractor wrote a script that would clear server logs. Then it would remove root access to machines and delete the data on them. Finally it would shut down the servers automatically.

The last script was especially evil. It would attempt to corrupt any systems it could find in the company. Then it would go after the backup machine, clear out the backups, and turn them off. This hacker was just plain thorough.

Luckily another engineer detected the original script that was to install all the other rogue code. Upon detection, he shut everything down in the company until they could figure out what was going on. That was the one smart move the company made. These rogue scripts could have done severe damage to the bank.

Props to The Inquirer for providing the facts for this blog post.

Microsoft Security

I just got a subscription to MSDN magazine from Microsoft. This is a good magazine to read if you program using Microsoft technologies. The latest issue had a lot of Microsoft specific security articles. Today I want to tell you about what I read. The topics were SAML, CAS, and STS. How is that for a list of acronyms?

SAML stands for Security Assertion Markup Language. It is based on XML. You can tell from the name. SAML is used for authentication between domains. For practical purposes, it helps implement single sign on. You type in your user name and password once. Then you can go everywhere and be automatically authenticated. You do not have to retype in your credentials.

CAS stands for Code Access Security. It is part of the .NET framework. CAS prevents untrusted code from executing privileged instructions. An administrator sets up the security policy for your machine. The .NET common language run time (CLR) then maps programs to code groups. These code groups have permissions set. The CLR then either allows or disallows the instructions to execute.

STS is the Security Token Service. A client wants to access a web service. The client first gets a token from an STS server. Then the client passes the token to the web service. The web service validates the token against the STS. Finally the web service honors the client request if the token checks out with the STS.

PKCS

PKCS stands for Public Key Cryptography Standards. They were developed by RSA Data Security. These standards act as a means of interoperability between the vendors out there. There are 15 parts, but numbers 2 and 4 have been rolled into PKCS #1.

PKCS #1 is encryption using the RSA algorithm. PKCS #3 uses the Diffie-Hellman algorithms. It is how you exchange a key between two people. PKCS #5 covers passwords.

PKCS #6 is the extended certificate syntax. It describes the extra information like e-mail addresses within certificates. PKCS #7 covers the use of envelopes. An example is S/MIME.

PKCS #8 is for private key encryption. I will cover PKCS 9 through 15 next time around. Be ready for things such as Cryptoki.