We tried a few of the "big company" combo SAN/NAS devices and found that they... well suck. They can't do all things well. They can either do Windows well, or UNIX well, or SAN well. But not all things well no matter what the marketing literature says. It is also very simple to end up paying a whole lot of money by the time you get the pieces and parts put together.
What we ended up doing is getting a SATA2 SAN that supports 5 simultaneous connections over gig copper. We connect to it over iSCSI. We have: - Mail Server mounting via iSCSI - DB server mounting via iSCSI - Windows file server that acts as a NAS, but is saving to the SAN via... yup, iSCSI - LINUX NFS server that acts as a NAS, but is also saving to the SAN via iSCSI
This ended up being way simpler and much more cost effective. And yes you can run SAMBA on LINUX, but this is way easier to manage and maintain.
First, two-factor authentication is pretty much two-factor authentication. There are moderate differences in the various forms, but that is usually not the driving factor.
The biggest and most overlooked issue is the requirement for client-side software and drivers. The various OTP solutions (SecurID, etc.) are zero footprint. They can be used from any computer. If portability is as imporant as strong authentication, you should consider an OTP solution.
Smartcards and biometric devices require drivers at a minimum. Most require some type of middleware. This means you will have to manage a software deployment and the devices can only be used from systems that have the software installed.
Smartcards provide crypto, which can be leveraged for SSO, secure mail, etc. but by far, most of these projects succeed or fail based on the ability to actually deploy and use the solution.
So, an RSA Key would be an asymmetric cryptographic key. An RSA (or SecurID) token would be the little key fob with the changing number. Methinks this is referring to the token, not key.
We force the vendors to enter via VPN. we use the VPN gateway to restrict each vendor account's access to only the IP addresses of the systems they need access to. Further, we occasionally use a packet sniffer to watch certain vendors.
We disable the account by default and require them to contact us and tell us what they are doing (change control) before letting them in.
If you store password data in the database, make sure that it is salted and then hashed. SHA1 is nice because of the 160-bit output value. This makes brute forcing the password extremely difficult.
If you collect credit card numbers, use asymmetric crypto to encrypt the card data immediately prior to writing it to the database. Do not decrypt and process it on the same box. Decrypt and process on a separate box. Depending on your security requirements, you can store the decryption key in software (worst), smartcard (better), or hardware security module (best) such as an nCipher nShield, or Chrysalis Luna. The last two keep the keys off of the physical host, making it nearly impossible to recover the private key without physical access to the host.
Some companies do choose to store the last 4-5 digits of the credit card number and the expiration date in separate fields in the database. This is for user convenience (you can display the numbers so that they know what credit card is being charged).
It goes without saying, but I'll say it any way; the host where the credit card processing takes place should be a secure, bastion host. The only connections allowed should be initiated from the host to the database. This should be enforced by firewall rules. The host should be in its own distinct DMZ.
Caveat, I work for a company that does PKI. Over the years I have deployed PKIs using technologies from Baltimore, RSA, and Verisign.
- Verisign's Onsite Lite >> There is not enough money in the world to make me ever eant to do business with these guys again. Crappy customer service, ignorant professional services, and in the case of Onsite, buggy software.
- USB Token holders (aladdin, hasp, etc) - smart cards
>> I'm guessing you are in a windows environment. A few notes. The USB ports on most corporate PCs are still on the back. Also YSB tokens *always* need software (drivers and middleware) installed on every desktop.
Smartcards are not a bad way to go in a homogeneous environment. Under Windows 2K and XP, any PC/SC compatible driver works with no additional software installed. Use a supported "Win2K/WinXP" card such as the Schlumberger Cryptoflex card and you don't have to do any desktop software installation or maintenance at all. It works out of the box.
Usually the lower overhead of smartcards makes up for the additional cost over USB tokens.
- What headaches is key recovery going to be? >> Its just a process. Virtual smart card solutions can help alleviate these problems.
- Is there any meaningful long-term competition? >> Not really for secure email or transaction signing. If your primary business problem is authentication, then yes, there are many other solutions that are probably cheaper and easier to manage.
- How reliable is the hardware once deployed? >> Pretty darn good from what I've seen.
- How is vendor support? >> Depends on the vendor. Note Verisign rant above.
- Is the integration with Win2k, Notes, etc both functional and seamless? >> Win2K is simple. Notes is a pain in the ass unless the company you are working with has done it before. Lots of gotchas.
- What policy administration issues do we need to be aware of? >> PKI will force you to clearly define your identification and authentication processes, which most companies lack definition for. You will also need to spell out all of your policies and processes and add in checks to ensure you follow them. You will see an increase in administrative overhead.
- What best-practice documents are available? >> There are a few good books. The biggest problem I see in the field is that there is a major disconnect between the "theory" of PKI and the practical realities. Find a knowledgeable consultant who can spend 5-10 days with you. A good consultant should be able to provide you with a "PKI vendor agnostic" overview of the current state of PKI and help you with a needs analysis. The outcome should be a realistic set of requirements you can use to shop vendors with.
- How locked in will we be? >> If your design is correct, you should not be locked in at all. The biggest issue here is ensuring you stick with standards and avoid vendor-specific toolkits/APIs that will lock you into their solutions.
- Can we enforce non-trivial PINS >> This is a function of the credentials store. Generally speaking, the answer is no. There are exceptions.
- What changes to your help desk workload and practices have resulted? >> Most companies I work with are surprised at how often they have to replace certificates. If the end users are trained and well communicated with, there should not be a huge increase.
First, you do not have to use a public Certification Authority. In this case you are issuing certificates to a user in order to conduct business with you. My guess is that you trust yourself, so you don't need the services of a public CA.
Next, ignore E-Sign. If this is repetitive business, you need to contractually negotiate what constitutes legally binding. It is much easier to live up to the standard of "legally binding" instead of the standard of "non reputable". The contractual agreement should cover the due diligence requirements for both parties (you are responsible for ensuring the identity of the person you issue a certificate to, they are responsible for protecting their private key and ensuring no one else can use it) as well as risk allocation (who pays if the system fails).
Next, contrary to what my fellow slashdotters will say, you most likely will need to use commercial software. People like having someone to blame for failures, especially where legal transactions are concerned. If the software fails, or has a security problem, you want someone behind the software license with deep pockets. Also, most accounts I see using the PGP-like solution require the end user to license their own copy of the encryption/signing software (this is very typical for banks). Using commercial software means you don't have to eat the administrative overhead of supporting the software.
Finally, I would get some budget and hire a consultant who has done this before. It is quite doable, but there are some rabbit holes you can fall into. Check with RSA or Entrust for a senior consultant with architectural experience. This is a place where I would go for a specialist, and not one of the Big 5 (or is it 4 now) or a local VAR. If you want to do "electronic" signatures instead of digital signatures, Silanis up in Canada is arguably the king of this area.
I think your choices are greatly affected by the content of the training and the intended audience.
In the past I have worked with media designers to develop CBT using Macromedia's Flash and Director that was designed to be distributed via the web, or CDs. We also used Lotus Screen Cam for demo's of different products. This was very effective when the content was not overly technical and the audience had reasonable technical skills. It was a poor solution when the content was technical.
My experience is that technical content requires more interactivity with an instructor. If you watch a technical class, you will see the instructor often has to rephrase things, or even reiterate a bit to help the trainee understand. In these cases we've tried CBT in combination with telephone training to limited success, and satellite (think video conferencing, the more modern approach) with better success.
A friend of mine pointed out some interesting facts about these three cities.
First, no natural disasters. Not susceptible to earthquakes, tornados, flooding, or fires (nothing to burn). Makes an ideal location for data centers and call centers.
Second, power. Hoover Dam. Need I to say more?
Third, within three hours (by air) of most any location in the US. Not to mention, cheap airfare and in the case of Las Vegas and Reno, cheap hotels.
Forth, Nevada corporations...
Fifth, low housing costs.
On the negative side there is the unbearable heat, the large amount of old people, and, well, the unbearable heat.
I suppose the ideal situation would be to have the corporate HQ and data center in one of these three cities and the developers all up in Ottawa. Best of both worlds!
1. Learn to write in a clear and concise manner. I studied print journalism and it has paid huge dividends.
2. Take a few good speech communication classes. Being able to speak in a clear, confident manner is increadibly important.
3. Learn how to make a clear, concise and *logical* argument. Try some classes on rhetoric.
4. If you plan to work in IT, take some classes in interface design or HCI (human-computer interaction). Most programmers/software developers suck at this. This will help you stand out.
5. Perhaps most cynically, my advanced degree trumps your certification/years of experience/etc. most every time regardless of what the degree is in.
Essentially, if you can write well, speak well, and think well, you can get a job in just about any career field. Simply having an advanced degree will get you farther than most anything else you can have.
I have worked as a computer security consultant for the last 8 years. I have a B.A. in Communications, and an M.Ed. in Educational Technology.
There are basically four security certification that merit mention when someone asks about it.
CISSP - Focuses on policy and practice. The most recognized out of the certifications (meaning people have heard of it. No comment on quality). Sponsored by ISC2 (www.isc2.org).
CISA - Certification for IT auditors. Accountants are probably the primary audience, but anyone can take it. Probably the second most recognized. Sponsored by ISACA (www.isaca.org/cert1.htm).
GIAC - The new kid on the block. Balances policy and technical knowledge. Third most recognized. Sponsored by SANS (www.giac.org).
SSCP - ISC2's more "technical" oriented certification. Few people have heard of this yet. Sponsored by ISC2 (www.isc2.org).
*Hard dose of truth follows*
Knowledge is only useful if a person can apply it. In cognative theory there is the concept of "transfer". This is the ability of a person to apply knowledge gained to real world situations. Cognative theorists would argue that without transfer you haven't really learned anything. *None* of these exams test for anything more that your ability to memorize large amounts of data. To that end, you will find many people with security certifications who have absolutely no ability to solve simple real-world, security-oriented business problems. Do not mistake certification for experience and the ability to solve problems.
*Cynical reality follows*
At this moment in time, the CISSP has the most value in the job market, and arguably in the industry. This is because it is the most recognized certification. It is also the certification that is easiest to gain through rote memorization. One of life's great catch-22s.
I won't comment as to which is the "best" as this is highly subjective. Do your homework. Figure out which one has the buzz in your specific area of knowledge/expertise and memorize on!
First, there is almost no demonstrable ROI for using smart cards for logon only. You are better off looking into time-based tokens (SecurID, Defender, etc.) as they are cheaper, easier to maintain, suport and administer, and better supported as an OS authentication method.
If you are set on cryptographic smart cards (my assumption), then you need something else to drive ROI. The easiest thing is to look at using cards for logon and S/MIME. The other way to go is to use the physical smart card an physical access device (HID and Honeywell can embed coils into the smart card).
Not to pick, but whenever I see this question it scares me. It typically means that someone is more infatuated with the technology than with really trying to solve a business problem.
Please, feel free to refute me if you think there is an ROI for smart card logon. I've never seen it.
Using smart cards with Windows 2000/XP is a two-fold problem.
First, you need to have the card manufacturer's Cryptographic Service Provider (CSP) installed. For Windows 2000/XP, the Schlumberger and Gemplus CSPs are installed and using a "Win2K Compatible" card from either of these vendors does not require the installation of additional software.
The second part to the involves getting a certificate in the correct format onto the card. Assuming you are refering to PKINIT, you will need to have a card with only a single certificate that follows Microsoft's "Smart Card Logon" profile. Additionally, you will need to do some configuration on the Active Directory side to make it work.
Microsoft summerizes the process in the following Knowledge Base article:
http://support.microsoft.com/default.aspx?scid=k b; EN-US;q281245
One of the hardest parts is finding a CA (besides Microsoft's) that will UTF8 encode the SubjectAuthName field.
Slashdot Mirror
We tried a few of the "big company" combo SAN/NAS devices and found that they... well suck. They can't do all things well. They can either do Windows well, or UNIX well, or SAN well. But not all things well no matter what the marketing literature says. It is also very simple to end up paying a whole lot of money by the time you get the pieces and parts put together.
What we ended up doing is getting a SATA2 SAN that supports 5 simultaneous connections over gig copper. We connect to it over iSCSI. We have:
- Mail Server mounting via iSCSI
- DB server mounting via iSCSI
- Windows file server that acts as a NAS, but is saving to the SAN via... yup, iSCSI
- LINUX NFS server that acts as a NAS, but is also saving to the SAN via iSCSI
This ended up being way simpler and much more cost effective. And yes you can run SAMBA on LINUX, but this is way easier to manage and maintain.
First, two-factor authentication is pretty much two-factor authentication. There are moderate differences in the various forms, but that is usually not the driving factor.
The biggest and most overlooked issue is the requirement for client-side software and drivers. The various OTP solutions (SecurID, etc.) are zero footprint. They can be used from any computer. If portability is as imporant as strong authentication, you should consider an OTP solution.
Smartcards and biometric devices require drivers at a minimum. Most require some type of middleware. This means you will have to manage a software deployment and the devices can only be used from systems that have the software installed.
Smartcards provide crypto, which can be leveraged for SSO, secure mail, etc. but by far, most of these projects succeed or fail based on the ability to actually deploy and use the solution.
So, an RSA Key would be an asymmetric cryptographic key. An RSA (or SecurID) token would be the little key fob with the changing number. Methinks this is referring to the token, not key.
...and see what happens when opinion on the Internet masquerades as legitimate news...
Um... encrypted VPN traffic terminates at the gateway. Not the server being managed.
It is common practice to run sniffers/IDS/IPS behind the VPN gateway.
At least in secure networks...
We force the vendors to enter via VPN. we use the VPN gateway to restrict each vendor account's access to only the IP addresses of the systems they need access to. Further, we occasionally use a packet sniffer to watch certain vendors.
We disable the account by default and require them to contact us and tell us what they are doing (change control) before letting them in.
Works for us.
Since the music is being used in a public performace, I'm sure he pays the appropriate ASCAP and BMC licensing fees...
Body of Secrets: Anatomy of the Ultra Secret NSA by James Bamford.
- Cool book on the NSA and the US' signals intelligence capability.
Stupid White Men by Michael Moore
- A look at America through the eyes of the director of Roger & Me
Good to Great by Jim Collins
- This is a re-read for the summer. Absolutely the most innovative business book ever written. Seek this out!
Emile by Jean-Jacques Rousseau
- Its that time again...
A couple of good practices...
If you store password data in the database, make sure that it is salted and then hashed. SHA1 is nice because of the 160-bit output value. This makes brute forcing the password extremely difficult.
If you collect credit card numbers, use asymmetric crypto to encrypt the card data immediately prior to writing it to the database. Do not decrypt and process it on the same box. Decrypt and process on a separate box. Depending on your security requirements, you can store the decryption key in software (worst), smartcard (better), or hardware security module (best) such as an nCipher nShield, or Chrysalis Luna. The last two keep the keys off of the physical host, making it nearly impossible to recover the private key without physical access to the host.
Some companies do choose to store the last 4-5 digits of the credit card number and the expiration date in separate fields in the database. This is for user convenience (you can display the numbers so that they know what credit card is being charged).
It goes without saying, but I'll say it any way; the host where the credit card processing takes place should be a secure, bastion host. The only connections allowed should be initiated from the host to the database. This should be enforced by firewall rules. The host should be in its own distinct DMZ.
-LW
Caveat, I work for a company that does PKI. Over the years I have deployed PKIs using technologies from Baltimore, RSA, and Verisign.
- Verisign's Onsite Lite
>> There is not enough money in the world to make me ever eant to do business with these guys again. Crappy customer service, ignorant professional services, and in the case of Onsite, buggy software.
- USB Token holders (aladdin, hasp, etc)
- smart cards
>> I'm guessing you are in a windows environment. A few notes. The USB ports on most corporate PCs are still on the back. Also YSB tokens *always* need software (drivers and middleware) installed on every desktop.
Smartcards are not a bad way to go in a homogeneous environment. Under Windows 2K and XP, any PC/SC compatible driver works with no additional software installed. Use a supported "Win2K/WinXP" card such as the Schlumberger Cryptoflex card and you don't have to do any desktop software installation or maintenance at all. It works out of the box.
Usually the lower overhead of smartcards makes up for the additional cost over USB tokens.
- What headaches is key recovery going to be?
>> Its just a process. Virtual smart card solutions can help alleviate these problems.
- Is there any meaningful long-term competition?
>> Not really for secure email or transaction signing. If your primary business problem is authentication, then yes, there are many other solutions that are probably cheaper and easier to manage.
- How reliable is the hardware once deployed?
>> Pretty darn good from what I've seen.
- How is vendor support?
>> Depends on the vendor. Note Verisign rant above.
- Is the integration with Win2k, Notes, etc both functional and seamless?
>> Win2K is simple. Notes is a pain in the ass unless the company you are working with has done it before. Lots of gotchas.
- What policy administration issues do we need to be aware of?
>> PKI will force you to clearly define your identification and authentication processes, which most companies lack definition for. You will also need to spell out all of your policies and processes and add in checks to ensure you follow them. You will see an increase in administrative overhead.
- What best-practice documents are available?
>> There are a few good books. The biggest problem I see in the field is that there is a major disconnect between the "theory" of PKI and the practical realities. Find a knowledgeable consultant who can spend 5-10 days with you. A good consultant should be able to provide you with a "PKI vendor agnostic" overview of the current state of PKI and help you with a needs analysis. The outcome should be a realistic set of requirements you can use to shop vendors with.
- How locked in will we be?
>> If your design is correct, you should not be locked in at all. The biggest issue here is ensuring you stick with standards and avoid vendor-specific toolkits/APIs that will lock you into their solutions.
- Can we enforce non-trivial PINS
>> This is a function of the credentials store. Generally speaking, the answer is no. There are exceptions.
- What changes to your help desk workload and practices have resulted?
>> Most companies I work with are surprised at how often they have to replace certificates. If the end users are trained and well communicated with, there should not be a huge increase.
-LW
Answers in no certain order...
First, you do not have to use a public Certification Authority. In this case you are issuing certificates to a user in order to conduct business with you. My guess is that you trust yourself, so you don't need the services of a public CA.
Next, ignore E-Sign. If this is repetitive business, you need to contractually negotiate what constitutes legally binding. It is much easier to live up to the standard of "legally binding" instead of the standard of "non reputable". The contractual agreement should cover the due diligence requirements for both parties (you are responsible for ensuring the identity of the person you issue a certificate to, they are responsible for protecting their private key and ensuring no one else can use it) as well as risk allocation (who pays if the system fails).
Next, contrary to what my fellow slashdotters will say, you most likely will need to use commercial software. People like having someone to blame for failures, especially where legal transactions are concerned. If the software fails, or has a security problem, you want someone behind the software license with deep pockets. Also, most accounts I see using the PGP-like solution require the end user to license their own copy of the encryption/signing software (this is very typical for banks). Using commercial software means you don't have to eat the administrative overhead of supporting the software.
Finally, I would get some budget and hire a consultant who has done this before. It is quite doable, but there are some rabbit holes you can fall into. Check with RSA or Entrust for a senior consultant with architectural experience. This is a place where I would go for a specialist, and not one of the Big 5 (or is it 4 now) or a local VAR. If you want to do "electronic" signatures instead of digital signatures, Silanis up in Canada is arguably the king of this area.
-LW
I think your choices are greatly affected by the content of the training and the intended audience.
In the past I have worked with media designers to develop CBT using Macromedia's Flash and Director that was designed to be distributed via the web, or CDs. We also used Lotus Screen Cam for demo's of different products. This was very effective when the content was not overly technical and the audience had reasonable technical skills. It was a poor solution when the content was technical.
My experience is that technical content requires more interactivity with an instructor. If you watch a technical class, you will see the instructor often has to rephrase things, or even reiterate a bit to help the trainee understand. In these cases we've tried CBT in combination with telephone training to limited success, and satellite (think video conferencing, the more modern approach) with better success.
-LW
A friend of mine pointed out some interesting facts about these three cities.
First, no natural disasters. Not susceptible to earthquakes, tornados, flooding, or fires (nothing to burn). Makes an ideal location for data centers and call centers.
Second, power. Hoover Dam. Need I to say more?
Third, within three hours (by air) of most any location in the US. Not to mention, cheap airfare and in the case of Las Vegas and Reno, cheap hotels.
Forth, Nevada corporations...
Fifth, low housing costs.
On the negative side there is the unbearable heat, the large amount of old people, and, well, the unbearable heat.
I suppose the ideal situation would be to have the corporate HQ and data center in one of these three cities and the developers all up in Ottawa. Best of both worlds!
Its pretty damn simple:
1. Learn to write in a clear and concise manner. I studied print journalism and it has paid huge dividends.
2. Take a few good speech communication classes. Being able to speak in a clear, confident manner is increadibly important.
3. Learn how to make a clear, concise and *logical* argument. Try some classes on rhetoric.
4. If you plan to work in IT, take some classes in interface design or HCI (human-computer interaction). Most programmers/software developers suck at this. This will help you stand out.
5. Perhaps most cynically, my advanced degree trumps your certification/years of experience/etc. most every time regardless of what the degree is in.
Essentially, if you can write well, speak well, and think well, you can get a job in just about any career field. Simply having an advanced degree will get you farther than most anything else you can have.
I have worked as a computer security consultant for the last 8 years. I have a B.A. in Communications, and an M.Ed. in Educational Technology.
There are basically four security certification that merit mention when someone asks about it.
CISSP - Focuses on policy and practice. The most recognized out of the certifications (meaning people have heard of it. No comment on quality). Sponsored by ISC2 (www.isc2.org).
CISA - Certification for IT auditors. Accountants are probably the primary audience, but anyone can take it. Probably the second most recognized. Sponsored by ISACA (www.isaca.org/cert1.htm).
GIAC - The new kid on the block. Balances policy and technical knowledge. Third most recognized. Sponsored by SANS (www.giac.org).
SSCP - ISC2's more "technical" oriented certification. Few people have heard of this yet. Sponsored by ISC2 (www.isc2.org).
*Hard dose of truth follows*
Knowledge is only useful if a person can apply it. In cognative theory there is the concept of "transfer". This is the ability of a person to apply knowledge gained to real world situations. Cognative theorists would argue that without transfer you haven't really learned anything. *None* of these exams test for anything more that your ability to memorize large amounts of data. To that end, you will find many people with security certifications who have absolutely no ability to solve simple real-world, security-oriented business problems. Do not mistake certification for experience and the ability to solve problems.
*Cynical reality follows*
At this moment in time, the CISSP has the most value in the job market, and arguably in the industry. This is because it is the most recognized certification. It is also the certification that is easiest to gain through rote memorization. One of life's great catch-22s.
I won't comment as to which is the "best" as this is highly subjective. Do your homework. Figure out which one has the buzz in your specific area of knowledge/expertise and memorize on!
-Laudon
First, there is almost no demonstrable ROI for using smart cards for logon only. You are better off looking into time-based tokens (SecurID, Defender, etc.) as they are cheaper, easier to maintain, suport and administer, and better supported as an OS authentication method.
If you are set on cryptographic smart cards (my assumption), then you need something else to drive ROI. The easiest thing is to look at using cards for logon and S/MIME. The other way to go is to use the physical smart card an physical access device (HID and Honeywell can embed coils into the smart card).
Not to pick, but whenever I see this question it scares me. It typically means that someone is more infatuated with the technology than with really trying to solve a business problem.
Please, feel free to refute me if you think there is an ROI for smart card logon. I've never seen it.
They do exactly what you are asking for. I have used their sister service pobox.com for years and have always been happy with their service.
Using smart cards with Windows 2000/XP is a two-fold problem.
k b; EN-US;q281245
First, you need to have the card manufacturer's Cryptographic Service Provider (CSP) installed. For Windows 2000/XP, the Schlumberger and Gemplus CSPs are installed and using a "Win2K Compatible" card from either of these vendors does not require the installation of additional software.
The second part to the involves getting a certificate in the correct format onto the card. Assuming you are refering to PKINIT, you will need to have a card with only a single certificate that follows Microsoft's "Smart Card Logon" profile. Additionally, you will need to do some configuration on the Active Directory side to make it work.
Microsoft summerizes the process in the following Knowledge Base article:
http://support.microsoft.com/default.aspx?scid=
One of the hardest parts is finding a CA (besides Microsoft's) that will UTF8 encode the SubjectAuthName field.
It can be done. Good luck.