I had an experience this weekend that made me think about policy and how it can be something to ruin your business very quickly. Interesting enough this was not an information security policy related event but the process of what I went through made me think about how a company can really screw up by not being aware of the global environment they operate in.
The incident ..... being a security guy I do take advantage of security aspects that are provided by others. My credit card company has a system whereby I can generate single use credit card numbers for online purchases. I can even use reward points for these purchases. With this in mind I was looking for an inexpensive monitor for my home office so I went online to BestBuy so I could see what they had and since there are two locations near me I could go and quickly pick it up. I found one that was suitable, quickly generated a credit card number and placed the order. Within half an hour I had the "come get it" email from BestBuy. It did mention for me to bring the email, my ID and the credit card. Well the card is virtual, generates and disappears, but I had the source card. Off to Best buy where they promptly refuse to allow me to pick it up. The associate claims they do not allow virtual credit cards for in store pickup. I ask why and the response "It is policy." Well it seems to be a silly policy since you can easily do a trace back to me with my ID and the email and the fact that it all matches the data I provided for the online purchase, which cleared the credit card check. "It is policy". Then he stepped in it deep - "But ... if you have someone else pick it up and you say who it is at check out then it is ok since they do not have to show the card."
WHAT!!!!!!!
Someone who skims my card and gets the number, CIV and expiry can go online, buy something with my card and put their own name as the guy picking it up - BUT - I cannot?
"It is policy"
It dawned on me - BestBuy created a policy many years ago when virtual credit cards did not exist and they had not updated that policy with this new paradigm in place. Sure a few years back it was good practice to want to see the card but to update the policy to let someone else pick up and not update it to handle virtual cards or currency?
Imagine now that this is a IT security policy. With the recent BASH vulnerability announced, would a company now start to look at where they are using CGI and Linux systems to see what they need to do from a policy perspective for future protection? A good company may even do an evaluation of other aspects of operations to see if there was any open-source code that maybe was also created before certain vulnerabilities were leveraged.
The lesson for me, outside of don't shop at BestBuy, is that security implementation and policy is not about a document or a configuration. Security is about taking what is happening today and ensuring that you understand how that impacts your business and mitigate any risks - look to the future but ensure you understand what you are doing today and what others are doing that may potentially put you at risk.
BTW - used the exact same method for a purchase at Apple - using that keyboard to type this post .... no card needed.
Monday, October 6, 2014
Monday, July 14, 2014
The Learning Process Seem Hard .....
Once again mis-issued certificates are in the news. I would like to be able to say that this will not happen again but it seems that not enough people are willing to learn the history of Identity Management to begin to implement mitigation means that would reduce the impact of these events.
This time around it was an Indian Government Agency, NIC, that was in control of the issuing CA. Part of the process did work here in that the Indian Government's Auditing reacted fairly quickly to the issue and revoked the Issuing CA and for now has no plans to put that CA back online. That being said the work that Google and Yahoo will have to do to ensure that vulnerable browsers and Operating Systems take the correct action to mitigate the risk is not insignificant. On top of that we do also have the case that we are not sure that Google and Yahoo were the only ones affected ... at least not yet.
The timing of this for me is quite interesting as I am currently working with a client who is looking at options for certificate based authentication, both privately rooted and publicly rooted. They will use a hosted service but I was very insistent that they make sure to implement smart card based authentication for all administrators and then to ensure to implement practices and policies of log reviews to ensure that the known administrators are adhering to policy.
Sounds simple doesn't it? Implement a stronger means of authentication for RAs and LRAs and then review the issuance logs, which can be done automatically. So given this why are people not doing this? Yes some are but there are still many issuing CAs out there that allow RAs and LRAs to login with userid/password.
If you are a corporate or organizational Security Officer I encourage you to do a couple of things:
This time around it was an Indian Government Agency, NIC, that was in control of the issuing CA. Part of the process did work here in that the Indian Government's Auditing reacted fairly quickly to the issue and revoked the Issuing CA and for now has no plans to put that CA back online. That being said the work that Google and Yahoo will have to do to ensure that vulnerable browsers and Operating Systems take the correct action to mitigate the risk is not insignificant. On top of that we do also have the case that we are not sure that Google and Yahoo were the only ones affected ... at least not yet.
The timing of this for me is quite interesting as I am currently working with a client who is looking at options for certificate based authentication, both privately rooted and publicly rooted. They will use a hosted service but I was very insistent that they make sure to implement smart card based authentication for all administrators and then to ensure to implement practices and policies of log reviews to ensure that the known administrators are adhering to policy.
Sounds simple doesn't it? Implement a stronger means of authentication for RAs and LRAs and then review the issuance logs, which can be done automatically. So given this why are people not doing this? Yes some are but there are still many issuing CAs out there that allow RAs and LRAs to login with userid/password.
If you are a corporate or organizational Security Officer I encourage you to do a couple of things:
- If you operate a CA or operate an RA/LRA for a hosted or public CA service then implement strong authentication for the credentials used in the issuance process. If your CA vendor does not support that ... CHANGE VENDORS
- If you operate RAs or LRAs ensure that you run checks on a regular (preferably daily) basis to ensure your RA/LRA personnel are not compromised. This could be fully automated through scanning of logs
- If you have not gone through the Trusted Root stores that are used within your environment you should have that task looked into and clean the roots that you do not use.
Again these are not difficult things but my experience tells me that these things are not being completed across the board. If you want to stay off the front page of technical blogs and magazines I would suggest that taking some of the points above and start to implement them.
Again - history is a wonderful teacher .... but you need to understand history and how that history affects what you do
Monday, February 10, 2014
Target and Snowden ... two cases with the same root cause?
As greater information comes out about the Target breach one begins to wonder if it and the method used by Snowden, to access the information that he disclosed, point to a fundamental misunderstanding when it comes to implemented "best practices" in information security.
I certainly agree that the range of implementations of different security architectures represents a broad range of very bad to good, when it comes to protecting access to information. I am also a believer in the balance between ease of use and "appropriate" access to information. I am not suggesting that one size fits all. What I am suggesting is that we have two significant examples here that point to, what appears to be, a glaring gap in what some would see as fundamental principles as it applies to access to information, that is, access should only be granted to the right people at the right time for the right reasons.
In the two cases here we have two very different organizations but at their core of operations you have two organizations that share data, both as a supplier and a consumer; interact with a broad range of organizations (Target's case it's suppliers and the NSA case it is contractors) and have legislative or contractual mandates to protect the data that they hold.
What is interesting is that in both cases we had entities able to have access to more data then they needed to have access to. Yes Snowden did go outside the box in some cases to gain the data but that was not caught, which points to the possibility that they were doing things correct on the front end but had weak audit mechanisms/checks to validate the implementation. In Target's case it is obvious that the external supplier that they were dealing with did not have access restricted to systems that were irrelevant to the relationship.
These are not the first cases of significant data loss occurring because of access to data that occurred indirectly. Fundamentally the RSA breach was the same thing ... in that case it was data being on a server that should not have been exposed in the manner in which it was. If a server does not have controls to restrict access appropriately then do not have exceedingly sensitive data on it.
Fundamentally organizations need to get back to data categorization and map that to data access. Data access however is not just a case of yes or no based on the credential you have but has to be considered in relation to the credential you have (considering strength, assurance level etc), situational analysis (Is something going on in the network that raises suspicion of activity such as excessive data egress), timing (Is access be requested at an hour that is inconsistent with past behaviors?) and other factors that may need to be considered based on the environment or data sensitivity.
This process of data categorization will lead to system dependencies that will need to be well documented in security and operational plans. Once these plans are implemented there also need to be the process of validation and audit/monitoring that needs to happen to ensure consistent operations.
Some would say "This is not rocket science ... people know this". I think more people are thinking of it now but if they have known it certainly does not appear to be widely implemented in a complete fashion.
I certainly agree that the range of implementations of different security architectures represents a broad range of very bad to good, when it comes to protecting access to information. I am also a believer in the balance between ease of use and "appropriate" access to information. I am not suggesting that one size fits all. What I am suggesting is that we have two significant examples here that point to, what appears to be, a glaring gap in what some would see as fundamental principles as it applies to access to information, that is, access should only be granted to the right people at the right time for the right reasons.
In the two cases here we have two very different organizations but at their core of operations you have two organizations that share data, both as a supplier and a consumer; interact with a broad range of organizations (Target's case it's suppliers and the NSA case it is contractors) and have legislative or contractual mandates to protect the data that they hold.
What is interesting is that in both cases we had entities able to have access to more data then they needed to have access to. Yes Snowden did go outside the box in some cases to gain the data but that was not caught, which points to the possibility that they were doing things correct on the front end but had weak audit mechanisms/checks to validate the implementation. In Target's case it is obvious that the external supplier that they were dealing with did not have access restricted to systems that were irrelevant to the relationship.
These are not the first cases of significant data loss occurring because of access to data that occurred indirectly. Fundamentally the RSA breach was the same thing ... in that case it was data being on a server that should not have been exposed in the manner in which it was. If a server does not have controls to restrict access appropriately then do not have exceedingly sensitive data on it.
Fundamentally organizations need to get back to data categorization and map that to data access. Data access however is not just a case of yes or no based on the credential you have but has to be considered in relation to the credential you have (considering strength, assurance level etc), situational analysis (Is something going on in the network that raises suspicion of activity such as excessive data egress), timing (Is access be requested at an hour that is inconsistent with past behaviors?) and other factors that may need to be considered based on the environment or data sensitivity.This process of data categorization will lead to system dependencies that will need to be well documented in security and operational plans. Once these plans are implemented there also need to be the process of validation and audit/monitoring that needs to happen to ensure consistent operations.
Some would say "This is not rocket science ... people know this". I think more people are thinking of it now but if they have known it certainly does not appear to be widely implemented in a complete fashion.
Subscribe to:
Posts (Atom)