The “three-legs” of support for information security

In the Information Technology (IT) world, technology is king.  But in information security (IS), technology is just one support of the overall IS function.  Since information security involves giving direction to people’s activities interacting with sensitive information, a balance must be achieved between the “three-legs” of information security management; people, processes and technology.  Let’s break these down individually.

People

Security begins with each individual, whether authorized, or unauthorized, accessing and protecting information. In many of these interactions, technology isn’t even involved (i.e. speaking to another individual, talking on the phone, physically handling paper records, etc.).  So the first leg of protection has to be “People”.

In order to start working with people you have to start with trust.  If you can’t trust your workers to only access that information they’re authorized to see, or you can’t trust them not to disclose sensitive information they know, then the battle is already lost.  Yes you can take disciplinary actions against an employee for a violation of a corporate policy, or criminal action in the case of fraudulent activity, but this is “closing the barn door after the horse gets out”. When it comes to interacting with people, proactive security activities are the better road to take.

Do periodic background checks – Doing a background check on people who handle sensitive information when they join the company is always a good idea, but don’t stop there, do periodic checks.  People’s lives change, and unfortunately not always for the better.  That trusted administrator who joined the company a decade ago may now be financially influenced to sell sensitive company information due to a long-term illness or layoff in the family.

Know who handles sensitive information – Seems a no-brainer that you’d know who has access to sensitive information.  The reality is, in today’s complex organizational structure, without a close examination, you may not discover who has this access.  Information, depending on the associated data a worker has access to may become sensitive without management’s knowledge.  The Navy did a study during World War II where a series of sailors calling home each had a small piece of information about their deployment.  When the war office put all this data together they learned where the ship was going, how long is was going to be there, its basic mission goals and other critical information that would have aided any enemies who were listening.  The Navy started the campaign of, “Loose lips sink ships” understanding that even the lowest ranks had information that could be detrimental if exposed.

Do security training for all people handling sensitive information – Making people aware of the policies and procedures around protection and proper access goes a long way towards achieving a good information security program.  The employee learns what is expected of them and the corporation gets a good security citizen that can also augment the company’s security personnel by keeping their eyes and ears open in reporting unacceptable behavior.

Create a communication channel of trust – Get affected workers involved in new security programs.  Allow business managers to voice their requirements.  Involve key stakeholders in security decisions.  As humans we have some of the most sophisticated communications capabilities among all the species on Earth, use them.  Throwing information security initiatives over the wall to managers and employees is unacceptable in today’s business environment.

Policies & Processes

OK, you have the eyes of the people upon you, so what’s next?  You have to provide guidance on what actions are acceptable and not acceptable to the organization.  It’s one thing to tell people they have to protect information, but you have to provide instructions on how the company wishes this to happen.

Develop policies and processes that make sense – I periodically review policies and processes for my clients.  There’s nothing worse than to find a series of policies and processes that don’t reflect the culture or organization of the enterprise.  Asking for people to stop their actions while they wait for someone to authorize an action that isn’t in their chain of command, doesn’t have this decision as a priority, or is difficult to contact will cause the process to fail.  When you create policies and processes they must reflect the real-world your organization operates under.

Create an “enforceable” set of policies and processes – I once worked with a company that had a policy that stated, “All sensitive information must be encrypted at rest.”  So I asked if this meant that every database and LDAP directory they had all ran encryption software.  Of course the answer was no, it was a best-practice policy developed by an outside consultant for the company.  So my question is “Why take the time and effort to write a policy or process if it isn’t enforceable?”  Either people won’t abide by it, or worse, they will create their own alternative processes that make their job actions easier, not necessarily making the company more secure.

Make the policies and processes easily accessible – Keeping these documents (electronic or paper) under lock and key doesn’t help anyone.  Distribute these freely to the management and workforce.  In addition, always note at the top of each document who the responsible person is for maintaining this document along with contact information.  People may need to review a particular policy or procedure in a time of crisis and having to take the time to hunt down the document may be the difference between a successful or unsuccessful detrimental activity to the company.

Update them on a periodic basis – Conditions change, opportunities come and go, legislative and corporate compliance efforts may grow, as such, a good company periodically reviews ALL their policies and procedures, but not all at once.  Create a review schedule that reflects the rate of change and resource availability of the company.  A company I worked with has about twenty-five corporate policies.  Of these, five are reviewed in detail each year meaning that every five years the entire set of policies get a makeover in a round-robin process.  Of course if you decide to do this, the information security office should work with executives to determine what the review cycle should be for their organization.

Ok, now that we’ve got the eyes of the people, we’ve given them direction and they’re protecting your information, now what?  You need to select tools to improve the efficiency and scope of this protection.

Technology

Technologies are not an end in information security; they’re a component of information security.  They should be selected to work with your people, policies & processes. 

Technology should be used to streamline and augment protection mechanisms – An administrator cannot physically review and approve thousands of e-mails that come into and out of a company.  But technological tools can do this very easily.  In those cases where an information security function is financially not viable, is too complex to implement in process, or too resource constrained to maintain a good security activity you should consider a technology solution.

Technology may require policy and process changes – The technologies you choose could influence how people securely access sensitive information.  As technological changes occur, training and policy & process changes may be needed.

Technologies are only as good as their configuration – I read vendor promises of 100% compliance, elimination of fraudulent activities, etc.  Well in theory maybe, in reality, not without a lot of work.  These tools have not been developed solely for the use of your company.  They need to be configured, or mapped, to your unique requirements.  Best practices and default settings rarely provide the optimal protection of information.  Don’t deploy any solutions until you’re satisfied they work as well, or better, than how you protect your information today.

Remember, technologies don’t get the blame when things go bad, you do – Treat technologies as tools.  Just like a bad carpenter, a hammer in his hand may not product the results you expected.  Relying on technologies to do your job is a fatal mistake; they can only go so far in providing information protection.  You are ultimately responsible to ensure the protection of your company’s information.

In the end, people, policies & procedures and technologies need to work in conjunction with each other. One of the main activities of a security manager is to keep these three in proper balance.  Only when they equally work together can you feel comfortable that your information security activities will support the needs of your company.

r

The ever expanding world of sensitive information

The other day I was clearing out old papers from my office and I came upon an official Tax Booklet mailed to me from the IRS through the postal mail.  In looking at it I noticed that they not only included my name and address on the shipping label, they also included my social security number. This got me thinking of the good ole days when personal information wasn’t worth much.  I can remember going to college using my social security number as my college ID number.  I can remember throwing away my old credit card stubs and paid bills with the number in clear text. And I can remember when I didn’t have a debit card so I didn’t have to worry about forgetting my pin when I went to withdraw money from my bank. But that’s not the world we live in today.  It seems that more and more pieces of information about us are being classified as personally identifiable information (PII); but not every piece.

So how does this affect today’s businesses?  Let’s look at what it took to preserve the sensitive information organizations protect today. In most organizations I’ve worked with they didn’t start their information protection program on a Monday and it was complete on a Friday, it took years and years to develop them. First they had to classify the “types” of data considered sensitive; financial, PII, health information, student, contractual, competitive, intellectual property, etc.  Next they had to discover what systems this information was being stored on.  Then they needed to discover who had access to this data.  Followed by what privileges they “should have” vs. “what they had” when they accessed sensitive data.  They then had to discover how this information flowed between the systems. They then had to write policies, procedures and processes to manage all these areas followed up by deploying tools to help enforce the governance they created.  All the while the organizations were learning, correcting their mistakes, locking down areas that had open access and putting in network and system controls to stem the flow of unauthorized access inside/outside the enterprise.  A daunting task, but a successful one for most.

But as I alluded to in the beginning of this blog, sensitive information isn’t in a steady state.  Today’s sensitive information isn’t your Dad’s sensitive information.  The issue that comes up is the fact that it took years, with many curves and blind alleys, to put in place the security protection programs that are in place today.  Unfortunately most organizations did this without formally documenting the steps they took.  While the outcome is great, the reality is the security protection program development process was informal and not repeatable.

As enterprises look at the next round of “what’s sensitive”, they’re finding they have to go back to square one and hopefully repeat the process they went through the first time, minus the mistakes and wrong turns.  The good news, many of the program development standards and technologies available today weren’t around when the organizations did this exercise the first time.  The bad news, since new standards and technologies are now in use, going back to square one may not be possible as the paths and tools have changed and now there’s a legacy program in place.

So what should people do?

Assume every piece of information is sensitive then back off:  Until every descriptor of us and the data we use is declared sensitive, or security technologies effectively guard everything, enterprise security personnel will need to periodically reexamine the protection needs of all their enterprise data.  If you have twenty-five descriptors of a person and fifteen of them are declared sensitive.  Develop overarching policies, procedures, processes and tools that can handle all twenty-five but only implement them for the fifteen needed today.  It’s better to turn on some components of security rather than rearchitecting them.

Keep a close eye on security trends: If you find that people are taking an interest in a piece of information you maintain, be proactive in securing it rather than reactive.  It’s better to grant access to what seems like public information than to pull back information from the ether that is now deemed sensitive.

Assume that information like name and address will be secured at some time in the future: Just like having a credit card number without the expiration date or CCV makes having this data worthless, if someone collects a lot of PII without the person’s name and address, this makes the PII worthless.

Look at “data at rest”, “data in motion”, and “data in use”: The sensitivity of a piece of data can vary depending on its state.  In defining your future security programs you have to recognize that the “state” of the data may be just as important as the other factors in its handling and storage.

Document, Document, Document: Avoid the “Big Mac Syndrome”, a person of importance being run over by a “big mac truck” with no documentation on how to handle the information they managed.  By documenting your various security protection plan phases’ processes, assuming you get promoted based on the excellent work you did, other’s can then follow the same steps taken by the development team when changes and enhancements are necessary.

I predict that in the coming years EVERY piece of personally identifiable information that digitally represents a person will fall under “sensitive information”.  This means, while it’s too expensive to securely manage this information today, you’ll be adding to, and expanding, your information security program in the next few years.

r

Take my information, please! – Social networking

It seems every day there’s another company who announces a data breach or other exposure of personally identifiable information (PII).  Of course once a breach has been made public, my colleagues and friends in the security world have a field day talking about how they should have protected “this” information and how they should have classified “that” information as sensitive.  Yet when I go out to the various social networks I wonder what they’re complaining about, they’ve all giving away their personally identifiable information already…..

On this blog space I’ve talked about how criminals are taking the easy way to get PII and credit card information.  Rather than attacking the credit card processors, and all their security mechanisms, it’s easier to get people’s PII by attacking companies that maintain the sensitive information they need for their activities – information brokers, insurance companies, job sites, etc.  – so they can apply for a fraudulent credit card using their victim’s good credit ratings or gain access to sensitive information their victim is authorized to see.  But is there an easier way?  Yep, how about just joining a social network?  Let me explain.

I just did an informal search around a few social networks and you might be surprised at what I found.  Put yourself in the position of an identity thief.  What types of information do you find valuable?

• A person’s name
• A person’s address
• A person’s age
• A person’s job title
• Where they work
• How long they worked there
• What they do
• Where they went to school (for password reset security questions and phishing attacks)
• What hobbies and places they visit (to figure out what they might have used as a password)
• Their spouse’s name
• Other information

So why even break into a small organization, with at least some sense of security, when all you need is a free social network account and some bots to find “friends”?  For example, check out some of the information I found on some sample sites I went to (names and vital information have been changed to protect the person’s PII):

Linkedin.com

I searched on friends of a friend of a friend (in other words strangers with virtually no direct relationship to me).  I found a guy that we’ll call Joe.  It turns out Joe is an HR Analyst for {blank} company (Hummm, someone with access to a lot of employee records).  Not only do I have his job history, but I know he received a BA in Business (1976-1978) from Minnesota State University, Moorhead.  The company is also known to use e-mail addresses in the form of “first initial,full last name@{blank}.com” (which I got from their “contact” page on their web site).  So if I’m a hacker, I’m going to send Joe a “special” e-mail; one that as soon as he opens the attachment will spawn a bot on his system so I can capture his key strokes showing his login information and IP address of the systems he goes to, including his company’s HR system.  I could send him an e-mail from a Nigerian Prince who wants to use his account to hold one million dollars but I think Joe’s smart enough not to open that one.  So Joe will receive an e-mail with and attachment and the header will say, “Minnesota State University, Moorehead Class of 1978 Alumni News”.  Thanks Joe, I’m sure you’ll shortly be helping me in getting all the information I need from your company!

Classmates.com

Again, supplying all the information I need to know about who, when and where someone went to high school (usually graduating between the ages of 17/18 so age shouldn’t be a problem to figure out either).  I did a search for someone I met at a financial institution who has access to a lot of sensitive data, we’ll call her Jane.  It turns out Jane belongs to Classmates.com. In doing a “Google” search, didn’t even have to have an account on classmates.com, I learned that Jane graduated in 1985 from Camden High School in Camden, NJ.  Hummm, guess a special e-mail from her high school alumni association is in her future (and I found Bob who graduated with her so he’ll be sending the e-mail, not me).

Facebook.com

I had to create an account on facebook.com but was able to randomly search for “a friend” on the site where I found “John Doe”.  It turns out that John is really open and friendly.  Not only did I find out where John lives, but that his favorite “Products” are pizza, the beach, and Reese’s (great password tries), his “Favorite Stores” are Will Smith, Hugs, and Bonfires, and his favorite “Websites” are FirefighterNation.com & FireRescue Magazine.  So John will be getting a special request to renew his FireRescue Magazine subscription and to verify his password, which the magazine will tell him is currently “reeses”.  Of course that’s wrong and John will click on the link (which doesn’t go to FireRescue Magazine at all but will look like it) and put in his correct login/password (to be tried on the real site where the hacker will get his mailing address and other PII he provided the magazine).

Myspace.com

My favorite.  People are very open about what they want to share with their friends on this site.  I did a random search for “Charlie” and found “Charlie xxxx”.  Seems Charlie is 24 years old living in Redondo Beach, California and attends California State University – Northridge where he’s currently getting a degree in Business Marketing/Management.  Charlie went to South High in Torrance California where he graduated in 2002. Charlie’s apparently doing pretty well in his studies as he’s now, “… the Director of Marketing/Advertising and Sales at {XYZZY}, LLC which is a production company that myself and a few good friends started in March 2006. Check us out at {XYZZY}.com.”  Don’t worry Charlie, I will.

I’m sure you get the point by now.  I personally use social networks but interestingly I’m being constantly harassed by the sites because my “profile is incomplete”.  I assume after this blog you know why.  Next time you are contacted by an organization apologizing about the possible exposure of your PII, don’t start bad mouthing the company until you see what you have already exposed on your favorite social network site.  You might find that it didn’t matter anyway as the information was public knowledge.

r

Training, the forgotten security enforcement tool

Before I begin, I just wanted to apologize for not having a new post this week until now.  It was for a very good reason;  I was authoring a security opinion article for Information Security Magazine.  If you’re interested in reading it I’ll point to the URL on this site when it’s released.  Thanks and keep reading. r  

Now on to the post……….

On this blog site I talk a lot about policies, processes, procedures and the tools and services that support them.  But one topic I haven’t really gone into a lot of detail on is the importance of security training.  You’ve probably heard the scariest question you can throw at a host, “What if you threw a party and no one came?”  As I’ve worked with organizations in the past, one thing I really look for in a security team is communication.  Not only is it important to have a good set of security standards and services; you have to “advertise” they’re there so people will embrace them.

I’d like to start talking about training by relating a true story that happened not too long ago. I was working with a huge multi-national organization which I’m sure just about everyone who reads this blog has used their services at one time or another.  As part of the engagement I asked if I could review their security policies to ensure they were complete.  Well the security analyst I was working with was proud of the fact that not only did they have a good set of security policies, but that they covered them as part of new employee orientation and they were available to any worker who was interested in reviewing them because they were on-line on their intranet employee portal.  But when my contact went to the portal to show me their policies, it took 20 minutes before we found the page they were on (and this was the person responsible for ensuring they were on the portal).  If this person had a problem finding the policies, there was an excellent chance that the organization’s employees couldn’t find them at all.

So why is this important?  Because in the world of security, your best tool against unauthorized activities is your workforce.  Going through the efforts of creating an enforceable security infrastructure but not getting the word out ensures that enforcement will be weak at best and may not even be possible.  By communicating what the policies and procedures of the organization are, you not only increase your compliance by workers but you empower the employees to be the eyes and ears of the security organization to ward against unauthorized activities and achieve greater protection of sensitive information.

So what training should you do?

• “Red team” training – It isn’t enough to have fully thought out policies and procedures on incident handling.  The “red team”, or the organization’s internal team responsible for handling security incidences, needs to have incident response practice training sessions.  Just as fire fighters, police officers, hospitals and others train for different levels of incident response, the manager in charge of the red team should also have periodic training on various security incident responses (even if it’s just white board exercises in a board room) . Practice does make perfect and as new scenarios are brought to light they should be incorporated into the training (i.e. cyber attacks of personally identifiable information (PII)).
• On-boarding/exit training – While a lot of organizations take the time to introduce the organization’s policies and procedures around authorized activities to new workers; they should understand the importance of abiding by the security rules of the organization and their understanding and acceptance documented.  However, I’ve also noticed that exit interviews don’t always review the security policies of the organization one last time.  It’s just as important to ensure workers leaving the workforce understand that even though they will no longer work for the organization, that they are still held responsible to ensure the confidentiality of any sensitive information they may have had exposure to while on their job (and the consequences of illegally taking sensitive information with them (like contact lists and client information)).
• Line-of-business Manager training – In most organizations the enterprise security team is not fully staffed enough to ensure compliance with organizational security policies throughout the entire company.  As such, specialized line-of-business manager training should be periodically conducted.  The purpose of this training is to clearly delineate where enterprise enforcement begins and ends and what is expected of the local management in the areas of enforcement, training, communicating local security requirements and incident handling.  I’ve seen a lot of line-of-business managers’ surprised faces when they learn that their local incident needs to be handled by them.
• Security personnel training – It’s assumed that those personnel responsible for the data security of an organization are fully briefed on the company’s policies and procedures.  However, whether they’re too close to the data, or too busy doing day-to-day activities, I find that most can’t quote all the security standards.  Many are focused on a small component of the overall infrastructure and may be unaware that a violation of a standard may be happening right in from of them.  For this group periodic reviews should be a high priority.
• Executive management training – While there’s generally a corporate security officer responsible for setting the direction and security policies of the organization.  Their activities should be periodically reviewed by other executives in the organization to ensure the policies are matching those of the organization’s overall goals.  This is best accomplished by a short training session with other executives on what policies are in place and what is under consideration.   Time should also be set aside for the executives to ask questions and to assure their objectives have been considered in the policies.

While I’ve tried to hit some of the most critical training sessions necessary for any organization’s security enforcement, each organization will have a unique audience or circumstances which will require additional training classes. As usual, I’m limited by the space requirements of a blog but if you have specific questions on what training is required for a unique instance in your organization I’d be pleased to answer your individual questions.  I can be contacted at rgamby@nycap.rr.com.  Keep up the good work and keep the communication channels open.

r

Selling IT services to business managers

As I talk to various organizations one question always comes up, “How do we sell this thing to our management?”  I’ll go into my thoughts on what you need to consider but before I do I want to relate a story that happened to me that changed my whole outlook on selling IT services to business people….

Early in my career I was working on a project with a client to architect an identity management solution.  Upon completion of what was a very wonderful experience, our proposal for funding and resources was sent to a VP of the organization for approval and submission into the budgeting cycle.  We’d ensured we dotted every “i”, crossed every “t”, had strong data around costs and deployment, and just knew this was a certainty for approval. 

Just before we expected the project to be approved, the VP asked to have the project managers come to his office.  We figured there might be some discussions about the numbers because of their size so we were prepped with our justifications, our analysis and our estimates when we walked into his office.  He had us sit down at his desk and he said, “I’ve read over your proposal and I’m getting ready to approve it if you can answer just one question.”  Thinking we had prepared for any questions he might have, we were ready to jump on whatever he asked.  He looked up and asked a simple question which we hadn’t prepared for and that left us speechless, “I see you’re proposing a technical solution worth a substantial amount of money.  The only question I have is how will this help me build our {widgets} better and/or cheaper?”  We had prepared to talk about how this project would improve processes, reduce risk, eliminate redundancy but had lost sight of the fact that the business didn’t care about infrastructure “stuff”, they wanted to be the best in producing their product at the greatest efficiency. 

Ever since that experience I’ve tried to focus on “business benefits” and not “infrastructure benefits”, a lesson I’ve shared with many people I’ve worked with and who have been better justifying their projects after my telling this story and working with them a bit.

Ok, so you probably aren’t concerned about what I learned and are waiting for me to talk about the topic at hand….

The first and foremost thing to understand is business speaks a different language.  Think about if you had a detailed message to give to someone and you spoke English and they spoke French.  The letters look similar and there may be some words that could be understood by both but the overall message is lost in the translation.  While IT project managers talk about improved user experience, reduction in duplication of IT services, policy enforcement, identity lifecycle management, modular infrastructures, etc., mid- to upper-managers talk about business need, operational efficiency, cost containment, risk management, regulatory compliance, competitive advantage, etc.  The words look similar and may be somewhat understood by both but they’re two different languages.

I instruct many project managers that if they’re not aware of their executive management’s year-end goals then they had better get a copy of their company’s annual report or talk to someone as high up as possible.  It may be easy to explain the benefits of a multi-million dollar provisioning system to IT project managers but explaining how this expensive piece of technology maps to the business managers’ overall goals for the company may be extremely difficult, if not impossible without some “language translation help”.

The next thing you have to remember is getting the stakeholders involved up front means you have an ally in the end.  Too many times, the project team responsible for scoping a new service or technology only talks to other technical personnel and don’t get line of business (LOB) managers or end users involved with the process.  “Throwing services over the wall” that benefit IT but not the business won’t sell very well outside the IT department. Stakeholders should participate in the business problem identification, requirements interviews, be kept informed on the progress being made during the analysis phase, and briefed on your services choice(s) before the final decision is made.  In all phases of the project you’re looking for “consensus”.  Not “approval” but not “against” either.  Remember if they’re not against you, they must be for you.  And the side benefit of getting the stakeholders involved is they’ll evangelize and socialize your project for you, a built in marketing team.

Mentioning services (not solutions), you have to sell services based on business functionality, not technology; drop the TLAs (three letter acronyms).  Selling an LDAP directory as an LDAP directory or a Data Loss Prevention tool as a DLP tool, will daze and confuse non-technical managers and end users.  When you sell a solution the sales pitch shouldn’t be, “We have a new directory service that supports LDAP, has 26 APIs, runs on UNIX and can be interfaced to your end system using your vendor’s native admin interface toolkit.”  A lot better sales pitch would go something like, “We have a service that will allow you to incorporate the data you need in your manufacturing process using a corporate-supported solution with little to no development costs to you allowing you to no longer need to manually input this data thus reducing any errors or missing data in your manufacturing process.”  If you were the manager of this group, which pitch would you want to hear?  The first uses a bunch of technical jargon where the second has; who has the cost of ownership (not the LOB manager), why the LOB manager needs it, what it will cost the LOB manager (little to no cost), and the benefit (reducing errors and having more complete information).  A LOB manager, and their boss, and their boss’ boss will understand these terms. LDAP: good luck.

If there is a high cost for the solution, prepare lower cost and other alternative recommendations.  Fixing a deficiency or adding a new service isn’t a bipolar decision.  There are generally several alternatives, not all involving technology that may be beneficial to the organization.  Exploring and documenting the alternatives are a way of ensuring something gets done even if the optimal solution is rejected.  After getting a “Dear John” e-mail from a manager rejecting a technology proposal, I’ve interviewed them to understand why the project was rejected.  Of course “cost” is the most common reason, followed closely by “the funds have been reallocated”, but pulling out one of the alternatives the project team had considered that met 80-50% of the stated goals at substantially reduced cost has sometimes gone through (many times management sincerely wants a solution to the problem the project team has addressed else they wouldn’t have allowed all the time and expense for the team to work on it).   

I could probably write a book on this topic but I’ve tried to highlight some of the top considerations in selling IT projects to management.  If you’d like to hear more on this topic, just leave a comment.  I’m willing to help you sell these things!

r

Where’s Waldo (the identity thief)?

The truth, he’s not in this picture, he’s on your partner’s site.  Case in point, last week Aetna Insurance Company reported a breach.  Well, technically Aetna didn’t have the breach, true they had a web site data breach of their recruitment site but it was “maintained by an external vendor”.  Of course to the 65,000 current and former employees that had their names, phone numbers, e-mail addresses, mailing addresses and possible social security numbers on the site – that also contained information for up to 450,000 applicants – they didn’t care who lost their information, just that it was stolen (Probably to be used to apply for fraudulent credit cards – see my blog, “LexisNexis breach, an example of the next generation of financial identity theft”).

To add insult to injury, Aetna didn’t even uncover the breach.  They found out about the breach earlier this month after, “…people began receiving spam messages that appeared to come from Aetna and complained to the company…” They’ve now contracted with an IT forensics company to investigate how the web site had been compromised but haven’t pinpointed exactly where the breach occurred.  They are also offering one year of free credit monitoring to the 65,000 people who were affected (I’d estimate the monetary cost to the company is probably around one-quarter to one-third million dollars).

So what can be learned from this unfortunate event?  I try to stress each time I work with a client that security doesn’t stop at the walls of the organization.  Not only do remote facilities, traveling employees and clients have to be protected, but you also have to ensure your partners are providing secure infrastructures for your information as well.  Traditionally organizations that enter into an agreement to represent them with a third-party look at the ethics, financial stability, ability to execute, and support capabilities of their potential partner (normally clearly spelled out in the terms of the contract).  

But what about protection of this information, is it in the contract?

Does the contract allow periodic, or on-demand, security audits of the partner’s processes, software, systems, and network infrastructures? Does it allow access for contracted forensic companies to examine a partner’s facilities in the case of an incident? Does it allow for recovery of costs that occur from a breach in the partner’s supplied services like credit monitoring, or recovery of fines or fees that may be imposed by a regulatory body? Does it allow financial recovery for the loss of reputation (an insurance company like Aetna wants to ensure it has the highest standing)? Does it allow a partner’s deficiencies in their level of data protection to be sited as a valid cause to terminate a contract without penalty? I see few partner contracts that address these and other conditions, around levels of protection and audit rights in the protection of an organization’s information being sent.  Note: I’ve found that one reason for lack of contract wording around this area is the fact that the legal departments of the organization, and their potential partner, don’t know that sensitive information is being communicated even though the IT department is usually aware of this fact.

Unfortunately a lot of legal staff are still coming up to speed when it comes to compensation and necessary legal clauses in today’s partnering agreements.  In the case of Aetna, they probably should have been doing more to monitor their partner’s security practices due to the nature of the information they were supplying them but I guess we won’t know how the breach occurred until “Waldo” is found.  Keep your eyes open; remember Waldo, the identity thief, won’t be wearing that red and white striped shirt and hat so he may not be easy to spot until he’s stolen you or your partner’s information.

r

Putting your eggs in one basket – finding the “suite” spot

Ok, so you’ve got a product, or a few products, from a Security or Identity Management vendor and either their Sales person has told you about their new “suite” of products or you have a new business requirement for a functionality that makes buying the vendor’s suite attractive.  I’ve seen this scenario play out a thousand times.  The problem, does it make sense to put all your eggs in one vendor’s basket or do you look around for individual best-in-class products that meet your new requirements?  A lot of times organizations take the easy way and lean towards the vendor already in place – they have a relationship with the vendor, or it’s easier to get funding because they’re on the “approved vendor” list; or it would just take too long to do a good analysis of the competing products.  But baring these factors, how does an organization decide?  Well, here are some of the areas I look at:

Composition of the suite: Vendors generally develop the products that make up their suite in four ways. They have an internal development team that produces them.  They purchase a company that has solution(s) that complement their existing products and integrate them.  They resell another company’s solution(s) because the value of purchasing the other company is too low, or they’re too big.  Or they get their marketing team together and create an umbrella brand for all their products whether they’re integrated or not (i.e. whiz-bang-security, whiz-bang-monitoring, whiz-bang-identity, etc.). 

In order to understand how the products in the suite work together you have to ask your vendor a series of questions.

• How mature is the product you’re looking at?  Is it at V1.0 where the rest of the products in the suite are at V12.0?  This might indicate a lot of fixes or support issues in the near term. If it’s a reseller agreement, or company purchase, is there an issue with inter-product integration within the suite or licensing consistency? 
• In the case of a reseller agreement, what is the relationship with the company? Is there a risk that the agreement will terminate or the reseller will be bought by a competitor? (This happened a few years ago when a suite vendor was reselling a product from a small company that was bought by their competitor.  Many of the suite vendor’s clients lost technical support and update capabilities) Is the suite vendor on the resellers early adopter program? If not, you could be getting releases up to 6 months later than the reseller’s regular clients.
• Are there separate configuration, administration and reporting setups between products in the suite?  And of course marketeering a suite can be the worst as this generally means a bunch of disjointed products have been branded together without near term integration (I once said a company known for this tactic had just mapped a whiz-bang-refrigerator under their product suite brand).
• Are there competing products in the suite and which ones are in the roadmap for the long run? This brings up an interesting problem when the functionality an organization needs is in the product not on the long term roadmap.  I had a client that purchased a suite which worked with two different directories for access.  But when the component using the directories was dropped for a competing product in the suite, this capability was no longer supported.
• Who supports the individual products in the suite?  Does the suite vendor handle support for all the products? Or in the case of reseller agreements, does the original vendor support their product(s) in the suite?  I’ve heard horror stories from clients where there was an inter-product interoperability issue within a suite and both the suite vendor and product vendor continued to point fingers at each other saying, “It’s their problem.” while the issue continued with no resolution.
• If professional services are used, who delivers the product and trains the organization’s administrators?  Again, I’ve heard stories of small resellers doing installation and training for large suite vendors where there was only one person who was flying around the world doing all the installs, or the professional services personnel had lower standards of quality than the suite vendor’s professional services, or where the delivery people didn’t speak the local language even though the suite vendor had a large, local presence in that country.  Ask a lot of detailed questions about the professional services team’s capabilities if you find the product you’re interested in is new to the suite.

A non-disclosure meeting with the vendor is generally required to understand, the sometimes, complex relationship between the products under the common branding.

Best-in-class vs. suite products: Ok, once you understand how the suite was created and how the products within the suite interact, it’s time to think about whether you go with the suite or an individual product.  This elicits another set of questions for consideration.

• Do we have the personnel to do both end system integration and inter-product integration with the other solutions we have?  I had a client that went with a best-in-class solution instead of adding another product from the vendor’s suite they already had in place.  The main reason was cost.  It was $1M for the best-in-class product and $2M for the suite addition.  The problem, after the deployment they found they spent $5M just in inter-product integration with the existing products for special programs and custom interfaces that had to be developed in-house.  It also took 9 months longer to deploy than their estimate of how long it would have taken to do the suite product.  Pretty compelling to go with a suite, until you get to the next question….
• How good are the products within the suite?  Not all products in a suite are best-in-class.  Like a car dealer once explained to me, “When we purchase a lot of used cars we have to take a few junkers in order to get some nice ones.”  In evaluating a suite sometimes you have to “average” their capabilities.  One product might be #1 in its capabilities, another might be #3 and another may be #27.  If you go with best-in-class tools, assuming the integration and management of the individual products don’t kill you, you generally will have a set of tools with better functionality than a suite of products (something that’s important to the end users).

Finally, the question that needs to be asked in these economic times, how secure is the company if you go with their suite of products?  After all, you’re putting all your expertise, security of your organization, and money into a company you hope will be around, at least until you get promoted into another area of the organization or retire.  I know many people would never have guessed 10 years ago that Sun Microsystems would be on the selling block.  Security and identity management products still have a lot of boutique vendors.  I’ve actually recommended to a few very large clients that if they go with a single company for their security or identity management that one scenario that they should consider is just outright buying the company.  It sounds humorous but if you’re investing millions in a product from a company worth tens-of-millions, buying the company would be a lot cheaper than having them go under, ripping out all the products and putting in another product suite. Not to mention the downtime and loss of business while this all took place.

So are suites better?  Yes and no.  It’s up to the individual organizations to take a hard look at their support staff capabilities, the timing of when they need their deployments and how much ownership they want to put into making the products work as an infrastructure service.  If the organization can’t satisfactorily manage an infrastructure of individual products, a suite just might be up their alley.

r

The fast pace of security, NOT

Well, after moving 1 ½ years ago, I’m in the final stages of clearing out the stuff I’ve accumulated for ages in the old house.  This weekend as I was going through my old office I found the conference handouts from the NETSEC ’98 conference I had attended.  Knowing that the documents were over a decade old, I figured they were destined for the rubbish bin.  But to my surprise, when I started going through the presentations, I realized just how relevant they still are today and it just made me sick thinking about how little progress we’ve made in the field of security.  Consider that in 1998 Windows 2.0 was a new operating system running on 386 processors, Bill Clinton was dealing with the Monica Lewinsky scandal, Disney’s Animal Kingdom just opened in Florida, Google was founded in California and Daimler-Chrysler was created by the two companies merging. You’d think we’d have done our part in the “march of progress”, but we didn’t.

In taking a walk down memory lane, some of the hot presentations at the conference were:

• Secure online banking
• Designing secure E-commerce architectures
• Deploying intrusion detection in your enterprise
• Denial of service: what has happened, what to expect
• Practical tips for information security policy
• How to avoid the danger of former employees
• Cryptography – Privacy for business and e-commerce
• Computer crime and forensic analysis of seized data
• Internet-based remote access
• Network security firewalls aren’t enough
• Internet malicious code attacks
• Counter measures to network security attacks
• New trends in network risk management

If you walked into a CISO’s office today and asked them to identify the hottest topics they face today, I bet without a lot of looking, you’d find 90% of those topics of discussion in the presentations I found.  I didn’t want to save these reams of paper but realized that they still make a good reference (and possibly good future blog topics).  Sad isn’t it.

I understand that the threats and risks to an organization are increasing and sophisticated but it seems that new and inventive ways of thwarting incidents would have gained some level of maturity, as hopefully we did.  Granted, security technologies are evolving, but they’re comparatively slow compared to the rest of the IT world.  I guess the saying; “A long journey begins with a single step” applies to the security field.  As long as we aren’t backing up, progress IS being made.

Just as an aside, I’ve decided to archive my RSA conference notes in a safe place and hopefully in another decade I’ll be able to look at them and see what wonderful progress we made in the early decades of the 21^st. century.

r

Provisioning is dead, compliance rises from the ashes

In my blog post, “An abridged (and unofficial) history of identity and access management” I talked about provisioning systems.  These systems, the big brothers of meta-directories, are business-driven identity management systems and are today’s prevalent systems used for managing the life-cycle of user credentials and rights.  So why would I declare them dead? This probably takes some back-story first…

The advantages that provisioning systems had over meta-directories was the concept of process flows.  In order to create and maintain a user’s privileges it normally takes several process steps (i.e. HR creating an employee’s initial information, creation of accounts on internal systems for employee resources, hiring managers approving job specific privileges, changes through promotion, etc.).  Provisioning systems provide a user interface for inputting these processes (meta-directories required configuration code or tables) and system interfaces to the “source systems” for enacting the changes.  But they also maintain logs of the activities for validation that the provisioning service’s processes and activities worked.  While nice to have, in reality, validating process activities through the logging files is unwieldy and only contains the information on what the provisioning system’s actions were.  If you need to validate that the action took place on the source systems, or validate that the local source system’s administrator didn’t make manual, unauthorized changes, you have to go out and collect the log information from each of the source systems as well.  While not as cumbersome as defining new flows with each source system connection, like meta-directories, having to, collect, collate and report on activities via the logs is generally not done due to the effort and expense necessary; not to mention that each log file contains different levels of information, if logging is even turned on.

Jump forward to today. In this regulation-frenzy society, most organizations are required to attest to having good processes and guaranteeing the protection and authorized access to sensitive information (i.e. PII, PHI, PCI, etc.).  This “compliance activity” is in the forefront of most C-level security and IT managers.  So while the IT department has their provisioning system collecting the information that these managers need, as stated above, they’re not the reporting tool.  Many of the same vendors that make provisioning tools also make compliance and reporting tools.  These tools have the ability to search out regulated and sensitive information on source systems by collecting their log files and querying their configurations.  Once this information is collected and analyzed, the compliance tool generates reports on configurations, potential policy violations, high risks, potential data loss, etc.  These tools are heavily sought after by many organizations that recognize the cost savings in effort and time needed to manually do this work.  The vendors see this and are attempting to step up and make tools that people want.  So there’s a natural technology-focus evolution occurring again.  Directory Synchronization evolved to Meta-directories, Meta-directories evolved to Provisioning Systems, and now Provisioning Systems are evolving to Compliance Systems.  The death of one type of identity management tool creates the birth of a newer, better type of system.

From an organizational point of view, just as I mentioned in the post on the history of identity management, as business managers started interacting with IT staff for provisioning, IT staff are starting to interact with the security organization for compliance.  In many organizations the identity management systems are now being referred to as “security systems”. The question that has to be answered is, “Will the provisioning system stay a standalone tool or will it be relegated to a module within the compliance tool’s architecture?”  I predict compliance tools will win but I suspect the answer is coming sooner than we know.

r

A tale of two breaches

This month two health organizations reported breaches, John Hopkins Hospital (JH) on May 13^th and the University of California, Berkeley University Health Services (UCBHS) on May 8^th.  While they both involved breaches they were in fact quite different: 

• JH’s breach was from an insider; UCBHS’ breach was from an outsider hacking into restricted computer databases in the campus’s health services center.
• JH’s breach involves fraud, 31 individuals with connections to JH have reported identity thefts since Jan. 20^th; UCBHS involves personally identifiable information (PII) loss.  
• JH had over 10,000 records compromised; UCBHS had more than 160,000 records compromised. 
• JH’s exposure came from authorized access to sensitive data that was used in unauthorized ways; UCBHS’ exposure came from unauthorized access to sensitive data and they’re unsure of how the thieves will use this information.

As I talked about in my previous post, “LexisNexis breach, an example of the next generation of financial identity theft”, “{Thieves are} going after the personal information of hard working people from other innocuous sources”.  Unfortunately these health organization breaches only enforce this statement. 

These two cases also show how broad the areas of defense must be laid.  In the case of JH it was a single employee who worked in patient registration that may have used her access privileges to review data on more than 10,000 patients while working at the hospital.  Not only was she authorized to access this information, it was part of her job to do so.  In these cases it’s difficult to monitor any unauthorized access.  Prevention of this type of activity has to be done in advance, periodic screening and background checks on the authorized employees (not just at hiring) and the possibility of video monitoring and review of their activities may have been the only recourses to stop this type of breach. Of course security training for employees, including notification of activity monitoring helps as well.

In the case of UCBHS, intruders intentionally hacked into the restricted databases.  In this case there are several solutions that may have prevented this:

• Installation of a Data Loss Prevention (DLP) appliance at the boundary of the organization to detect unauthorized access.
• Better SDLC process in the development of the applications that accessed the databases to check for vulnerabilities in the code.
• An “air gap”, assuming this sensitive data is not used outside the medical center to keep network access to internal access only.
• The use of multi-factor authentication technologies for accessing the sensitive data.
• The possibility of encrypting the sensitive data at rest as it’s stored on the database to prevent unauthorized people from viewing the data.
• Periodic penetration testing of the network to ensure unauthorized network access fails.

And I’m sure there are other processes, procedures and additional technologies that would have helped.

An interesting final point to these stories, while many more records were breached in the UCBHS incident, the JH breach has actually resulted in fraudulent activities for those affected by the breach.  It’s been well know, and worth mentioning again, that of the breaches that occur, unauthorized insider activity breaches usually result in actual financial and fraudulent losses to the organization and the people who have their data lost. There’s truth in the old saying, “Keep your enemies close but your friends closer”.

r