Home

I’ve commented recently on Vormetric Data Security Blog on their article regarding “IEEE  Data Breach Demonstrates The Need for Increased Data Protection Measures”. My comments DID NOT touch the IEEE ‘case’ itself, but in general the behavior in wild and lack of some important aspects I feel should be in order.

Here is my post for the Vormetric blog:

Response to IEEE Data Breach Demonstrates The Need for Increased Data Protection Measures

I think Paul you hit the important factor here: Classifying the information assets (sometimes called as DATA too).

What comes for the increased data protection scope, there is obviously more that is visible to plain eye. Data security should include taking care of basic confidentiality, integrity and availability questions of the data during the whole life-cycle of its existence. From its obtain from the store, usage of the data, till the disposal of it. Like any “physical” equivalent.

The IEEE Data Breach is somewhat important demonstration in many ways. While not knowing all the details, it feels (well, I feel that is..) that IEEE might not understand the all aspects of the data being managed within the system. This puts IEEE in basket with most of the organizations, unfortunately.

Simply put: Organizations do not know what data IS important nor classify them.

Taking example: The passwords.

While having passwords in clear/semi-cleartext residing in FTP server is potentially a bad discipline of operational security (OPSEC) practice, organization may not understand that US, the PEOPLE using multitude systems are lazy, ignorant and not willing to sacrifice our convinience over security by selecting several different passwords for different systems. I bet 90% people have same passwords all-around Interweb, on environments which security or even intentions to manage it in legimit way is not known.

Sure, people using same passwords is NOT IEEE:s issue, but understanding of such ignorant habits people have IS.
That would solely be an forerunner to secure credentials enough. Just an example of OPSEC which touches information life-cycle
management in very self explanatory way. During the data life-cycle, it will be managed in several different ways.

Data may exist in different forms such as structured database information, tables or as a plain scanned TIF files of billing processing
Some of the steps allow securing the data, even encrypting it, while some of steps bans data to be secured by encryption.

All this, however, is part of the careful planning which involves defining the operational security, defining security controls and among these + lots of other steps – defining how data should be protected in variety of forms it may have. (While this may be seen simple, not every organization is just mature enough for this.)

Taking another example: Having encyption keys in HDD.

Not too long time ago, an security application handling key management for mountable hard disk encryption (encrypted mount) stored encryption keys in computer memory for granting “convinient access” to user while the hard disk was mounted as a next available disk letter.

Everything went ok, until someone figured out that hard-disk hibernation caused the encryption keys being visible in memory dump while booting with another operating system, hexed out the data from hibernation and opened the mountpoint. This was not ultimate example of poor key management, but gives an idea how difficult it actually is, while talking only a single laptop.

Even worse examples can be found of having encryption and signing keys within same server available for mostly anyone having some sort of administrative access. Guess how many have access to them and where they are now? How about securing the security stuff too?

Conclusion:

A bit, say technical approach this time. While we are pretty sure that we are not able to change ‘ourselves’ and our bad discipline for even our own operational security posture, I demand encryption as an excellent tool to secure data either in transit or stored in. But there is a catch, keys. While encryption as a function itself may not ne tricky, key management is. Here comes the OPSEC standpoint. Without having encryption and especially its key management as crucial part of security management discipline, having it part of the daily operational routine, someday organization shall found themselves locked out and keys in.

Organizations should develop, enforce and maintain, within their operational security practice, a ENCRYPTION STANDARD. It sounds worse than it may be. Without it, organization develops the wheel each and every time again, AND is surely NOT going to have it as part of their OPSEC nor data life-cycle practice.

Encryption. Good, even mandatory stuff in right hands.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s