doBoard

do… Web Application Development and Security

Posts Tagged ‘Confidentiality’

What Is Security, Really?

Monday, November 12th, 2007

You get a different answer each time depending on who you listen to:

“It’s simple – patches, firewalls, anti-virus and the latest security products.”

The product vendors would like you to believe that.

“Preventing and fixing known security holes like XSS, SQL injection and CSRF.”

A good web developer might say that.

“Efficiently detecting and blocking hacking attempts.”

Spoken like someone who has been in the trenches. Whack-a-mole at Internet speed.

“Complying with security rules and requirements.”

Smells like bureaucrats. Hopefully the thousands (!) of requirements aren’t constantly changing, poorly defined, contradictory, or ill-conceived…

With more variations than we can count, there has to be a better way to get a handle on security. So what’s the bottom line?

Security is keeping bad events to a minimum.

That’s my simplest, broadest and most fundamental definition of security. Everything else derives one way or another from that basic goal.

So what does it mean to keep “bad events” to a minimum? What are these bad things?

It’s bad to lose control of sensitive information, like credit card numbers or passwords, allowing it to go where harm can result.

It’s bad to lose integrity of your information and your systems, allowing data to be altered, systems to be broken into, transactions to be falsified or erased, etc.

It’s bad for services to be unreliable or unavailable to those who legitimately are trying to use them.

As the news headlines remind us, there’s a growing community of people who are actively trying to make those bad things happen, with a wide variety of increasingly powerful motivations, tools and knowledge.

So what to do about this?

First, identify what you have that needs protection.

That might be sensitive customer data, confidential business information, computer-based services that are vital to business operations, and so forth. Understand what it is, where it resides, and how it’s processed and transmitted by your systems.

Second, understand the risks and damage that can result from problems with protection.

Where are your systems vulnerable? How much damage would be caused by leaking medical records? Tampering with financials? System takedown? How likely is it that such things will happen? What will that mean in terms of money?

Third, decide what protective measures to take.

You might want people to prove their identity before they can access private information on your system. You might want security audits of your financial systems. You might want to test your systems to ensure they’re not easily taken down. There’s a large menu of security controls including the things mentioned at the beginning of this post. And now you’re in a position to make intelligent choices balancing risks vs costs and setting priorities.

Fourth, implement your chosen security controls.

Have qualified people do this correctly. Clear enough tasks off their plates so they can focus on getting this done. Ensure they have the organizational support to make reasonable progress.

Fifth, continue to re-evaluate and update your security over time as changes happen.

This may require management attention, periodic reviews and gap analysis, and one or more workers who have security management as their primary responsibility. Ideally everyone in the organization will take ownership for the security aspects of what they do.

This approach will help ensure that the right things are protected to the appropriate degree, avoiding excess and preventing or resolving deficiencies in an efficient way. By taking a step back, and thinking of security in terms of the fundamentals, it becomes much clearer how to proceed and where to focus your efforts.

By doing this you’ll be well on your way toward keeping bad events to a minimum.