Comments for BlogInfoSec.com

Comment on Why Information Security Professionals Should Learn Texas Hold ‘em Poker by Navin

Navin — Fri, 18 Jul 2008 06:19:36 +0000

Agree with you Gary. I think that the business would actually like us to be calculated risk takers. Business leaders are all about taking calculated risks so that they can effectively execute on business strategy. Since we are best placed to make decisions regarding acceptable risk relating to information security, if our risk appetite is significantly different to that of the business, then we will either pull them back or pitch them forward. We’ve got to calibrate infosec risk against business operational risk, financial risk, etc. and make decisions regarding information security in the same vein.

Comment on An Analysis of the Privacy Rights Clearinghouse “Chronology of Data Breaches” and Implications for Information Security Professionls (pt. 1) by john doe

john doe — Thu, 10 Jul 2008 01:38:28 +0000

Why use PRC for the data when they get their data from Attrition.org’s DataLoss project?

Comment on PCI DSS Position on Patching May Be Unjustified by Adam Shostack

Adam Shostack — Mon, 30 Jun 2008 15:33:58 +0000

Thanks for the mention, Jeff! I’m glad we inspired you to do this, and I’ve posted some thoughts in response at http://www.emergentchaos.com/archives/2008/06/in_the_land_of_the_blind.html

Comment on PCI DSS Position on Patching May Be Unjustified by Jens Laundrup

Jens Laundrup — Mon, 30 Jun 2008 15:32:45 +0000

Well said Jeff.
I would be willing to bet that they (The Payment Card Industry) do not follow their own patching mandate. It reflects the overall problem with PCI DSS, that it is too prescriptive but fails to meet the intended objective. We can draw a similar parallel to the Department of Defense where they often have a checklist that they have to go through to show compliance with a security directive. The problem with them is you can show compliance with the checklist or with PCI and be inadequately secured, thus meeting the letter of law but failing at the intent. It is time for the PCI to start thinking about adopting a different tactic.
In my opinion, certification to ISO/IEC 27001 would do much more to meet the intent of PCI DSS than PCI DSS does today.

Comment on Medical Identity Theft: Your Money or Your Life by Kris

Kris — Fri, 20 Jun 2008 17:53:35 +0000

I wonder how accurate your scenarios really are? I guess the incorrect blood type makes some sense, as there could be conflicting information in your files and the doctor would look at the most recent, but wouldn’t it be more likely that you’d still be listed as diabetic along with whatever other conditions the person who stole your medical identity might have? In other words, wouldn’t the more likely case be that you end up listed as having prescriptions that you don’t actually use, but that might conflict with another medication that the doctor wants to prescribe you? That would be something that the pharmacist would be the most likely person to catch, and would be a tipoff that your medical identity (really, just your health insurance info) had been compromised.

Of course, universal health care would get rid of this problem entirely, but that’s neither here nor there…

Comment on Assessing your Organization’s Network Perimeter (pt. 2) by Rene w/ NCP

Rene w/ NCP — Tue, 17 Jun 2008 19:44:11 +0000

What should be mentioned as (one of the many) details would be that users within a company using WLAN although physically within the confines of the building are to be treated as remote access users. Someone outside on the street with a laptop and a malicious intent should be able to detect and possibly participate within the WLAN if not secured enough, as if they’re within the building and as one of the users. It’s therefore imperative to realize that physical and virtual perimeters do not necessarily coincide!

Another point would be how far do I want to ‘extend the perimeter’ and use the right ‘technology’ to fulfill the requirements:

Incidental access to internal resources can best be facilitated with SSL-VPN access. This allows for a limited access to internal resources by those that need it; such as suppliers/consultants/contractors and so on. This doesn’t require the user to install a ‘client’, but merely downloads the code within the browser and uses the browser to access the internal resources, and this access can be carefully controlled centrally on the SSL-VPN gateway.

Conversely a full time employee may require to have access to the ‘regular’ resources he would normally have at his desk, while he’s on the road. An ‘full access’ or ‘LAN emulation’ (working remotely as if one is sitting at one’s desk) VPN solution would be a better suited option. This would imply that the latter’s work platform is secured; not only the communication between the two points, but the remote user’s device has become an extension to the corporate network perimeter; and thus should be protected accordingly. Why attack the corporate ‘perimeter’ firewall, when one can attack and possibly use a remote access user’s machine as a stepping stone into the corporate network?!

Comment on Why Information Security Professionals Should Learn Texas Hold ‘em Poker by Gary

Gary — Tue, 17 Jun 2008 08:42:49 +0000

Speak for yourself, Kenneth. Not all infosec pros are “risk adverse” as you say (I believe you mean ‘risk averse’, by the way). Risk aware, maybe, cautious by nature but not risk averse. To get things done in The Real World, most of us realized early in our careers that outright principled risk aversion sets us against the rest f the organization. It’s the root cause of naive ISM functions commonly being known as The No Department.

I’m not saying we should be The Yes Department either. Mostly I’d settle for a “Yes If …” or “No Unless …”, so long as it leads to incremental improvement and a greater level of knowledge, understanding and most of all accountability for our business management colleagues who are paid to make the difficult decisions. And there ARE situations in which it is totally appropriate to say No! NO! NO NO NO! The trick is to pick your battles, and beware the scars.

Comment on Agility and Risk Compensation: Exploring the Connection by Jens Laundrup

Jens Laundrup — Mon, 09 Jun 2008 17:11:20 +0000

I believe that the key is not that the policy fails but that the tools and processes necessary to support the policy are not put in place.
Patrick makes a great point about a policy that, though well intended, does not take into account the situation where 70+ passwords need to be maintained and remembered (even if it was more than 5 it would be pertinent). This raises the need for one of three efforts to resolve the situation:
1. The policy needs to be changed so that he is in compliance (not very desirable).
2. A single sign-on system needs to be set up for Patrick and those in his situation so that the passwords can be updated as required per policy but they are accessed through a separate system (a better system though it still relies on the weak username/password system).
3. A different system, such as a combination of a Smart Card and Biometric scan with a PIN, needs to be put in place so that the Username/Password system can be eliminated. The most expensive solution but it would enable compliance with not just the policy but the intent of the policy.
Thus, helping secure the environment through policy needs to be backed up with a reasonable manner/system/process for compliance. Too often this does not happen because of a well intended IT or security manager wanting to create a secure environment without thinking through the ramifications for the few (for the many, the password policy usually deals with one or two passwords only). In design engineering, this is often referred to as maintainability, in IT/security, this same scrutiny should be applied. We could call it “compliability” but what it really is: common sense.

The concepts of agility and risk that Jeff wriites of are greatly needed in modern IT environments. In addition, supplementing the what and how with why is very important to ensure that the users truly understand that it is not just to annoy. But as Patrick illustrated, policy needs to be tempered with “compliability”.

Comment on Agility and Risk Compensation: Exploring the Connection by Patrick Florer

Patrick Florer — Mon, 09 Jun 2008 16:06:10 +0000

just a couple of comments about the password example:

not convinced about the relationship of risk appetite to your subject matter - policy non-compliance may be much simpler than that.

For example, I must have 75 different accounts - company, financial, software support - that require passwords.

So why do I write them down?

It’s not because I want to circumvent policy and it’s really got nothing to do with risk appetite - it’s
because I cannot remember them all.

Why do I resent having to change them every so often?

Because it’s a hassle, because I cannot remember the last n passwords, and because my job is not to be a creator of strong passwords.

Why don’t I comply with policy? Because the policies may not make sense for what I do.

What can security do to improve my life?

Design password policies that are relevant to different levels of access/different roles - for some things/roles, who cares? The data just doesn’t matter.

For other things, maybe strict policies are the right way to go.

As for taking control out of my hands - if you can do that in a way that doesn’t completely tie me down, then great.
But if your approach is going to force me into a box, I will resist you and ultimately defeat your misguided efforts, thereby possibly creating a security problem that I don’t really wish to create, but have no reasonable way not to create.

fyi - I am somewhat new to infosec, but have spent 27 years in IT on all sides of the fence - really like your ideas about agility and risk, but am just taking the user’s point of view in these comments.

Comment on Bad Behavior - Thoughts on the Malicious Insider by Alex

Alex — Tue, 03 Jun 2008 14:15:28 +0000

To pile on….

In addition to the “not helpfulness” that Gary pointed out - those numbers, like any global/national/industry level statistic have meaning only in context. A specific entity (business, gov’t, etc…) will actually find the past 10 years of history a more meaningful metric, defined by what an insider incident *is* in their context.

It’s kind of like trying to tie your budget to an industry norm. Who gives a rip what the rest of the industry is spending? Your spending has to be in the context of management’s tolerance for risk.