Know What You Must Protect…

Folks, in order for security to work, you need to know what you are protecting. More importantly, your users need to know what is important and sensitive to the organization. You must also believe your data is worth protecting.

If you do not know what to protect, you will experience data leaks and disclosure. Companies need to know what data is important to them. This includes defining the information and developing policies to govern the use and handling of information.

Another important aspect is respecting others expectations of you to protect their data from unauthorized disclosure. Data leaks and blatant disrespect or regard for laws or privacy has a tendency to keep InfoSec pros up late at night wondering what went wrong or how do we fix this. Case in point: The state of California court system thought it would be okay to post medical records, social security numbers, images of checks, and other highly sensitive data on a website for all to see. Where do I begin? First, here is a link to an article about this: http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9081858&intsrc=hm_list

A fun tidbit from the article:

“But the court’s IT director defended the practices, saying that documents are being posted on the Web site in accordance with California laws and that finding data such as Social Security numbers is akin to ‘finding a needle in a haystack.'”

Oh, I feel much safer now. Let me post sensitive, Personally Identifiable Information (PII) on the web. It will be so hard to find…I promise. Yes, search engines are incapable of indexing anything, so things will be safe. By the way, I followed the law when I did this, so all will be fine.

Jeez. You have to be kidding me. This person and anyone else who approved this needs to pack up their desk and move down to storage room B. Mr. Whitehead, the IT Director for the court system is also only aware of five instances of sensitive information. He has been unable to locate some examples given in the article. So, how do you approve of data being posted if you have never seen it or know of its existence?

You can’t. If you have no idea what a dataset contains, there is no way to know if you can safely disclose this information. Essentially, some believe that all data should be posted and when someone on the web notices something isn’t quite right, we will fix it….in due time.

In the IT Director’s defense, his team was most likely told to create a site and post all the records by some person higher up the food chain. We all know what happens when we question authority… However, when will people learn to do the right thing or question something that just doesn’t seem right?

On another note, lets talk server security. This is closely related. A few words to the wise: lock down your server. A unpatched, unsecured, and unmaintained server are a hacker’s best friend. This is somewhat related to my previous rant in that if you do not know what types of servers you have or the software they are running, how do you secure them?

Baselines of various machine roles, the software and operating systems they host are required. This will ensure that you know what is on a machine and can roll back to something that is reliable should something go astray. In addition, if something happens to your organization in light of a disaster, you will be able to rebuild a machine without guessing. However, one other critical factor here is change management (CM).

All changes to any equipment baseline must be vetted and approved by some type of change control comittee. This comittee should consist of members from various parts of the organization, including management, helpdesk, IT security, system administrators, user representatives, data  and system owners. Why? Well, one small change could really compromise the security of your system and data. In addition, that same change may impact people across the organization and they should all be able to voice their opinion and concern. Also, this is a good CYA method. If something goes wrong and the department was respresented at the CM meeting, the department or person can’t say they didn’t know, although they will, or at least they will try. Test your proposed changes on a non-production system.

Picture this fun conversation at a company:

Bob:      Lets roll out the patches to the database servers since they were just released. All will be okay, I promise.
IT Pro: What, you want to apply patches to a production system?
Bob:      Yeah, why not. The vendor, Big Ca$h Cow, said the patches shouldn’t affect the systems.
IT Pro: Bob, do what your career can handle. (Thanks Sean!)
Bob:      But, ahh…umm…
IT Pro: Let me guess, you applied them and did not test or back-up the systems?
Bob:      Ahh, no. Why would I do that?
IT Pro: Go stand in the corner for your time out Bob.

Once you test them, document your changes. Submit these proposed changes to the CM board for final approval along with your test results. Once approved, go wreck havoc on your SysAdmins…they will love you for it. By the way, this brings up a very good point: In order to avoid looking like a fool during a CM board meeting, check with your SysAdmins first. Make sure what you are proposing isn’t unreasonable and will not break stuff. Otherwise, you may just have to put that dunce cap on afterall and stand in the corner. Afterall, your name is on the line if you bring the enterprise to its knees.

You get the point. Know what you must protect when it comes to assets. By assets, I mean not only your physical equipment, but your data as well. Without your data, your company and equipment is useless. In addition, make sure everyone understands the importance of safeguarding your data. If Joe User does not believe your data is valuable, then you have problems that go deeper than what technology can handle.

This is just something else that keeps me up late at night… 

Let me hear your thoughts in the comments.