« Learning from the Physical World - Case Study is Poor Security Engineering | Main | Secure Coding Advocacy Group »

Comments

shrdlu

In a lot of cases, I think we should turn our efforts first to re-aligning our processes before we go buy more technology. There is a lot of money you can save by tackling business issues first; many security issues stem from those and then you don't have to resort to building systems that fight what the business is trying to do.

Kai Roer

It is due time to have IT-security people focusing on the business aspects of things. One thing are the spendings that is way out of proportions - another thing is the lack of interest and understanding of core business values of many IT-security people. Add to this the lack of interest of ICT and security from any white-collar, and there is no surprise we have this situation.
Business is about maximizing profit by acceptable risk. Not about minimizing or removing risk.
Any business professional is doing this every single day. What is needed is the IT-security guys to understand that they are only part of the security structure in the company, and that their purpose is to support the business processes.
I say that business people handles risk every day - they understand and rely on risk assessment and management to do their jobs. So they do understand the basics of security.
But do security people really understand business? Do they care? Or is their only interest to check out the new, cool features in the latest FW or NAC? If so, then, well, sorry, your job is to help the business maximize its profits - not to spend a lot of dollars by investing in the latest blue and red blinking diode device to stash in your rack!
If you get offended - well, sorry. Time to wake up, perhaps?
Now, I will have another cup of coffee and continue my day.

MSP

Unfortunately, Corporate America thinks security is "alignment of policy".

Software and system designs are handled by the architecture group . . . in high-level "Go West, Find Gold, Avoid Danger" specifications. Then those documents are sent to offshore developers who make major technical design decisions - usually without parental control. Finally, those systems are deployed on servers and network infrastructure built by a third party (three-letter) vendor - usually without any legal responsibility for application security (development or deployment).

Ask how these systems are protected and you'll hear the "policy" chant.

In order to improve the security position we need to perform a review of production and the processes we use to bring solutions into play.

Policy is important . . . but the hackers really don't care about policy, or if you are "in alignment" . . . if you use inferior development, deployment or configuration techniques they will own you.

The comments to this entry are closed.