We are living in the age of the Internet. It seems like everyone has a presence on the Internet these days. People can now perform research online, read books online and even shop online. Large amounts of sensitive information flow through the veins of the internet on a daily basis. In order to protect this data we turn to our dear friend known as SSL (Secure Sockets Layer).
SSL is a protocol used to protect sensitive data flowing over the Internet from unauthorized parties. SSL verifies that the site claiming to be XYZ Bank is really XYZ Bank, and then encrypts the information traveling between the user and XYZ Bank. SSL is used when you buy the newest book from Amazon, or when you win that newest item on e-bay. SSL has become a cornerstone for protecting most sensitive data that is sent over the Internet.
In light of the fact that SSL is so important to Internet security, it is odd that vulnerabilities related to SSL implementation are found in many organizations. I have performed many vulnerability scans and it is amazing to see the amount of vulnerabilities, related to SSL. In honor of the many SSL implementation vulnerabilities I continue to find on a daily basis, I figured that this would be a good time to talk about a couple of them.
The first vulnerability I would like to discuss is the use of SSLv2. SSLv2 has many security flaws, but I am going to focus on the ability to downgrade the encryption used to establish SSL connections. Generally encryption negotiation of SSL connections works as follows: Suppose that a web server supports LOW, MEDIUM and HIGH levels of encryption. A user needs to connect to the server to perform some kind of action (such as online banking). The user supports SSL connections using LOW, MEDIUM and HIGH levels of encryption. In most cases the server and user will choose the highest form of encryption both of them support. Therefore the server and user will connect using HIGH encryption since both user and server support this level of encryption.
SSLv2 has been found to have a Ciphersuite rollback attack (Page6: http://www.schneier.com/paper-ssl.pdf). This attack works as follows: Suppose that a web server supports LOW, MEDIUM and HIGH levels of encryption. A user needs to connect to this server to perform some kind of action. The user supports connections using LOW, MEDIUM and HIGH levels of encryption. An evil hacker sits between the user and the server. The evil hacker intercepts the user’s SSL request, and modifies the request in order to make the server think the user only supports LOW encryption. Although both the user and the server support HIGH encryption, the connection between them is established using LOW encryption.
In most cases it is trivial to disable SSLv2. On new versions of Microsoft Windows SSLv2 can be disabled by modifying the underlying system’s registry. SSLv2 can also be disabled in Apache by making small changes to the httpd.conf file.
Disable SSLv2 in Windows: http://support.microsoft.com/kb/187498
Disable SSLv2 in Apache: http://apachehacker.com/kabir/security/disabling-weak-ssl-v2-support-in-apache-server.html or http://adamyoung.net/Disable-SSLv2-System-Wide
The second vulnerability I would like to rant about is the availability of weak encryption settings on a server, which could be used to establish SSL connections. It is not uncommon to find weak encryption settings enabled on a server. One such weak encryption algorithm is named DES. DES stands for Data Encryption Standard and only uses a 56-bit key to encrypt data. In April of 2006 DES was broken in nine days at a cost of $10,000 in hardware costs. Within a year the average time needed to break DES encryption was reduced to only 6.4 days (http://en.wikipedia.org/wiki/Custom_hardware_attack#History). It is important to note that when using DES encryption the possibility exists that an attacker may be able to see what you are sending in only 6.4 days. This is a rather scary thought! If an attacker were able to find your credit card or social security number in 6.4 days would you be concerned? The answer in most cases is a resounding YES!
The majority of weak SSL encryption vulnerabilities can be fixed rather easily. Most versions of Microsoft Windows can have weak encryption disabled by simple registry changes. Apache can disable weak encryption through simple changes in the httpd.conf file. In order to protect consumer data it is vital to disable support for weak encryption.
Disable Ciphers in Windows: http://support.microsoft.com/default.aspx?scid=kb;EN-US;245030
Disable Weak Ciphers in Apache: http://qaix.com/java-programming/487-339-ssl-server-supports-weak-encryption-vulnerability-read.shtml
Unfortunately I cannot address all SSL vulnerabilities in a single post. Time would fail me if I were to talk about Self Signed Certificates, Signature Verification Failure, X.509 MD5 Signature Collisions, Improperly Used Certificates, or Expired Certificates. To summarize SSL is a critical protocol used to ensure Security on the Internet and I have found it to be broken in many implementations. Now I ask you. How will you help defend the integrity of the Internet?
-Gary McCully
Read more!
Friday, January 15, 2010
Thursday, January 14, 2010
Writing Security Policies and Procedures
Anyone who has ever written a set of policies and procedures knows how time consuming, headache ridden and tedious they are to create. For those of you who are in need of updating or creating new policies and procedures, this blog will be going over some things to keep in mind. We’ll also go over tips to making your writing easier for you and easier for your users to understand.
Whether you’re just starting to write brand new policies and procedures or you’re doing your yearly updates on existing ones, I think the thing that everyone needs to keep in mind is simplicity. So that means, for any lawyers that may be reading this, you guys aren’t allowed to write these. This also means that the techie-guys that don’t know how to speak to normal people, you aren’t allowed to write these either. There are some companies out there that have policies that have the procedures right in the same document, and this single document spans hundreds of pages. Who will honestly read and follow that?
Now I know there are a ton of policies and procedures that are needed for different aspects of business but we are only going to look at the one that most people see: the End User Security Policy. The ideas we cover for this policy can easily be applied to any other policy you’re putting together. This end user security policy is notoriously filled with jargon that lawyers and techies love to throw in there. People, you have to realize that your end users need to be able to read and understand this policy so that they can easily remember it and apply it when necessary. They shouldn’t be long, there’s no need for that. The policy should be short enough that people can read and interpret it within 10 mins. Any longer than that and your end users will read half of it, maybe skim the rest of it and throw it in a big pile of papers on their desk. That creates two problems: 1. they didn’t read the whole thing, and 2. they won’t sign off on it that they did read and understand it.
Many end user policies are not enforceable based solely on the language used in the policy, or the fact that the policy doesn’t set metrics on what will happen if you do break the policy. The policy has to be enforceable, and when you are writing the policy you have to think of what you would do, seriously, in the same situation. If you say, you have to set a strong password for your windows login, there’s no way around that in a domain, so you don’t have a choice, you have to follow that. But let’s say you specify to your end users that if they receive corporate mail to their phone they have to have it password protected. Are you going to do that on your phone? Do you have a way to enforce that? Are you planning on running an internal security assessment to test this? If you find a user not doing that, what is the penalty? Is the penalty the same for every user? (The answer to that question had better be YES! Otherwise you’re going to be talking to those pesky lawyers about discrimination!)
What would you do if a user brought their home laptop in and plugged it in to the corporate network? Or worse, a wireless access point? What is the policy on that and what are the repercussions? What about non-employees such as contractors, visitors and such? Make sure to set the policy on this stuff, and remember to make it enforceable. Now if you say something like, the person who does this is fired, then what are you going to do if the CEO brings his son to work? His kid gets on the network just to use the internet. Are you going to fire the CEO?
What security methods are you going to make your end users aware of? Do they need to understand what drive encryption is or how to use it? Your end users may be complete tech novices, but your security policy/end user information technology policy should try to lay out what a user needs to know. And in this they need to understand the expectation of privacy. The expectation of privacy shouldn’t be documented too much here because you should have logon banners on every single network device that can be logged into. But you should explain what the banner says and what it means. And technically, if you don’t remove the expectation of privacy on a company computer or network device, then your user still maintains it, so make sure you stay consistent.
Obviously if your end security policy exists then you need to have an end user security procedure document as well. Every policy document should have a corresponding procedure document. And this procedure document needs to be referenced in your policy document. So, for instance, if your policy states that you have to make sure Windows Updates are installed every month, you should follow that up with something like, “Page 7 of the End User Procedures document explains how to do this.” You can’t expect your end users to know what Windows Updates are, let alone how to install or make sure they are installed every month. Try to do this as often as possible. It may take a lot of time to set up initially, but you can cut down on a lot of IT helpesk calls if you reference your procedures and keep all of this documentation easily accessible on the corporate intranet website. C’mon, throw a dog a bone. We aren’t the police here, we’re here to help, not criminalize.
Security doesn’t only mean network equipment either, now does it? Physically speaking, how do company employees get in the building? Do you require swiping an ID badge at every outside door? How about pin numbers or cipher locks? What doors do you not allow people to use unless emergency? Who gets keys to the building? What’s the policy for getting an ID badge or set of keys to the building? There are a lot of things to think about from an end user perspective. Be sure to go through every possible scenario that your company has and address it in your policy and explain how to do it in your procedures. Again, what about non-employees in the building? Do you require people without badges to show proof of who they are or ask questions on how they got in?
How about protecting intellectually property? What is the company policy for that one? This one is a touchy subject that needs to be discussed with some folks at the top of the chain. If you can get the Director of HR, the CEO and your CIO/CSO to give you their opinions on this first, you’d be in a better place to write this policy. Either way, when writing this policy, you have to make sure you are consistent. Any contradictions in your policies and procedures and you can throw these out the window.
Lastly, now you need to follow what you wrote and so does everyone else in the company. That means that all employees should review the policies once a year and sign off that they read them. Encourage people to ask questions. Get a training group together if needed. And if you think you’re going to get away with not having to follow your own document, you better believe other people are going to try their best not to follow it as well. If you made the cool-aid, you better drink it, unless you’re a malicious person by nature, then you shouldn’t be making cool-aid, let alone writing security policies. If you follow these simple tips, I promise that writing your company information technology and security policies and procedures will be much easier, not to mention that your end users will follow them much better.
Read more!
Whether you’re just starting to write brand new policies and procedures or you’re doing your yearly updates on existing ones, I think the thing that everyone needs to keep in mind is simplicity. So that means, for any lawyers that may be reading this, you guys aren’t allowed to write these. This also means that the techie-guys that don’t know how to speak to normal people, you aren’t allowed to write these either. There are some companies out there that have policies that have the procedures right in the same document, and this single document spans hundreds of pages. Who will honestly read and follow that?
Now I know there are a ton of policies and procedures that are needed for different aspects of business but we are only going to look at the one that most people see: the End User Security Policy. The ideas we cover for this policy can easily be applied to any other policy you’re putting together. This end user security policy is notoriously filled with jargon that lawyers and techies love to throw in there. People, you have to realize that your end users need to be able to read and understand this policy so that they can easily remember it and apply it when necessary. They shouldn’t be long, there’s no need for that. The policy should be short enough that people can read and interpret it within 10 mins. Any longer than that and your end users will read half of it, maybe skim the rest of it and throw it in a big pile of papers on their desk. That creates two problems: 1. they didn’t read the whole thing, and 2. they won’t sign off on it that they did read and understand it.
Many end user policies are not enforceable based solely on the language used in the policy, or the fact that the policy doesn’t set metrics on what will happen if you do break the policy. The policy has to be enforceable, and when you are writing the policy you have to think of what you would do, seriously, in the same situation. If you say, you have to set a strong password for your windows login, there’s no way around that in a domain, so you don’t have a choice, you have to follow that. But let’s say you specify to your end users that if they receive corporate mail to their phone they have to have it password protected. Are you going to do that on your phone? Do you have a way to enforce that? Are you planning on running an internal security assessment to test this? If you find a user not doing that, what is the penalty? Is the penalty the same for every user? (The answer to that question had better be YES! Otherwise you’re going to be talking to those pesky lawyers about discrimination!)
What would you do if a user brought their home laptop in and plugged it in to the corporate network? Or worse, a wireless access point? What is the policy on that and what are the repercussions? What about non-employees such as contractors, visitors and such? Make sure to set the policy on this stuff, and remember to make it enforceable. Now if you say something like, the person who does this is fired, then what are you going to do if the CEO brings his son to work? His kid gets on the network just to use the internet. Are you going to fire the CEO?
What security methods are you going to make your end users aware of? Do they need to understand what drive encryption is or how to use it? Your end users may be complete tech novices, but your security policy/end user information technology policy should try to lay out what a user needs to know. And in this they need to understand the expectation of privacy. The expectation of privacy shouldn’t be documented too much here because you should have logon banners on every single network device that can be logged into. But you should explain what the banner says and what it means. And technically, if you don’t remove the expectation of privacy on a company computer or network device, then your user still maintains it, so make sure you stay consistent.
Obviously if your end security policy exists then you need to have an end user security procedure document as well. Every policy document should have a corresponding procedure document. And this procedure document needs to be referenced in your policy document. So, for instance, if your policy states that you have to make sure Windows Updates are installed every month, you should follow that up with something like, “Page 7 of the End User Procedures document explains how to do this.” You can’t expect your end users to know what Windows Updates are, let alone how to install or make sure they are installed every month. Try to do this as often as possible. It may take a lot of time to set up initially, but you can cut down on a lot of IT helpesk calls if you reference your procedures and keep all of this documentation easily accessible on the corporate intranet website. C’mon, throw a dog a bone. We aren’t the police here, we’re here to help, not criminalize.
Security doesn’t only mean network equipment either, now does it? Physically speaking, how do company employees get in the building? Do you require swiping an ID badge at every outside door? How about pin numbers or cipher locks? What doors do you not allow people to use unless emergency? Who gets keys to the building? What’s the policy for getting an ID badge or set of keys to the building? There are a lot of things to think about from an end user perspective. Be sure to go through every possible scenario that your company has and address it in your policy and explain how to do it in your procedures. Again, what about non-employees in the building? Do you require people without badges to show proof of who they are or ask questions on how they got in?
How about protecting intellectually property? What is the company policy for that one? This one is a touchy subject that needs to be discussed with some folks at the top of the chain. If you can get the Director of HR, the CEO and your CIO/CSO to give you their opinions on this first, you’d be in a better place to write this policy. Either way, when writing this policy, you have to make sure you are consistent. Any contradictions in your policies and procedures and you can throw these out the window.
Lastly, now you need to follow what you wrote and so does everyone else in the company. That means that all employees should review the policies once a year and sign off that they read them. Encourage people to ask questions. Get a training group together if needed. And if you think you’re going to get away with not having to follow your own document, you better believe other people are going to try their best not to follow it as well. If you made the cool-aid, you better drink it, unless you’re a malicious person by nature, then you shouldn’t be making cool-aid, let alone writing security policies. If you follow these simple tips, I promise that writing your company information technology and security policies and procedures will be much easier, not to mention that your end users will follow them much better.
Read more!
Subscribe to:
Posts (Atom)
Posts
