Security From Scratch: Getting the Lay of the Land
by Dennis Kuntz
“You rush a miracle man, you get rotten miracles.” – Miracle Max, from The Princess Bride
When building Security from Scratch, the challenge is in undertanding the situation from the start. Once the team is identified/assembled, the focus shifts rapidly to getting a handle on the security posture of the organization. This is not an “assessment” in a formal sense, but is more involved than simply checking for a firewall and antivirus.
Each situation is unique, but here are the areas I consider in my tactical review so I can understand what challenges lie ahead and form my plan of action:
- Information Security Policy
- Network/Perimeter Security Posture
- SDLC Security Policies/Procedures/Practices
- Applicable Compliance Requirements
- Security Awareness
I’ll share my approach and thinking below – but want to hear from you, too. Are there other areas you would include, avoid or otherwise consider? Leave a comment or send an email and we’ll expand together.
Information Security Policy
This is an area open to debate, but I like to check for and review the existing security policies. It provides insight into what, if anything, has been done. It generally provides clues, too, to why decisions were made.
I’ve found two major approaches to Information Security Policies:
(a) a monolithic approach where the policy encompasses all areas with details
(b) a piecemeal approach where you have a very general document that references more detailed documents.
If I get to choose, I prefer the piecemeal approach. It allows employees to get an overview of the policy and all of the areas covered, without overwhelming them with too much all at once with one huge document they’ll never read.
With the “piecemeal” approach, the details can be spelled out in the referenced documents that are easier to draft, update, and distribute.
Understanding the current approach and structure helps form a picture of the current environment. Here are some questions to ask when considering the existing Information Security Policy:
- Does a policy exist?
- Who wrote it, is it strictly boilerplate, and/or has it been reviewed by stakeholders and approved by management?
- Are the policies being followed?
- How are changes made/approved?
- Who currently maintains the policy?
Network/Perimeter Security Posture
Now, while I suggested just checking for firewalls and antivirus aren’t enough, it doesn’t mean they should be skipped. It’s too easy to limit one’s assessment of security posture to just those kinds of elements. With that said though, this is definitely something that should be included.
In addition to getting a good idea of the network architecture (diagrams, etc.), here are some questions to ask regarding the network and perimeter security posture:
- Is remote access allowed? If so, how – VPN, SSH, nothing?
- Are firewalls , WAF’s (Web Application Firewalls), and/or IDS/IPS’s employed? Where? Who manages/maintains them and their rule sets?
- Does your company have/maintain a DMZ?
- Is wireless access allowed from your premises (including both network access as well as “open” wifi)?
- Does your company have any resources/assets in “the cloud”?
- If in “the cloud”, what control does your company have over the security of resources, vs. those that are simply “built in” to the services offered?
This is obviously not a comprehensive list (if you think I missed something key, drop a comment).
The main focus is to get a tactical understanding of the network and potential points of exposure. While tactical, this allows the identification of strengths and weaknesses in the current layout to form the path to advance the posture.
Once the tactical review is done, it is important to run internal and external assessments to test the baseline performance of the existing controls. Ideally, this should include both comprehensive vulnerability assessments as well as comprehensive penetration testing. This can be easily handled in-house if budget is a challenge.
SDLC Security Policies/Procedures/Practices
It should be obvious that companies that conduct business on the “Internet” , develop software, or has any measure of internal development, that SDLC (System Development Lifecycle) practices are important as they relate to security.
However, this also matters to companies with only a web site that was created externally and is hosted/maintained by a third party ASP (Application Service Provider), with no internal development. When getting the lay of the land, take a look at the accepted development practices to make sure they take appropriate security measures into account.
Here are some questions to can ask :
- Who “owns” the SDLC?
- Is security specifically addressed in any SDLC documentation, especially regarding applicable best practices (i.e. OWASP Top 10 for web application development, buffer overflows for vulnerable languages, etc.)?
- Is there any formal secure development training available for developers?
- If third parties/outsourcing is used for development, are security practices published and/or open for review?
- What is the current state of security awareness among the developers, architects, etc. (this can be assessed by one-on-one interviews with developers, architects and managers)?
As with the Network/Perimeter Security Posture section, being able run assessments and have penetration testing done will go a long way toward establishing the effectiveness of current controls.
Applicable Compliance Requirements
If the company is subject to any compliance requirements, it is vital to establish the current state of compliance. I will be covering this topic in more detail in a later post, but here are some questions you should ask:
- Is the company subject to government compliance (SOX, HIPAA, etc.)?
- Is the company subject to non-governmental compliance, such as PCI-DSS?
- Does the company need to remediate any recognized compliance violations and/or is there a deadline for any existing compliance efforts?
- Regarding existing compliance efforts, where/how far in the process is your company?
- Who or what department oversees any given compliance effort?
As noted in the first installment of this series, establishing relationships with other departments –especially regarding compliance – can go a long way toward achieving your company’s compliance goals.
Security Awareness
While “Security Awareness” can mean different – and specific – things to different people, I’m referring to it here in more general terms. In essence, you need to take a look at your company’s current behavioral and cultural stance and openness toward information security. Here are some questions you should ask:
- How much support will you have from stakeholders? From management? From everyone else?
- Related to the previous question, how much latitude will you have in making decisions – will you get to run the show, or will you end up having to be an order-taker?
- Is your position the culmination of a concerted effort to “become more secure”, or is it the result of a begrudging attitude to achieve a bare minimum? The answer to this one may take some effort to answer honestly….
Turning Your Eyes Toward Defining – and Achieving – Success
Once you have all of this in place – your team and a good idea of where you are – you can begin to understand what is needed to define “success” and the metrics needed to quantify that success.
Identity Management in 13 Easy Steps
by Ioana Justus
If you were asked to throw a few million dollars out the window, would you do it?
If yes, let me know where and when – I’ll happily wait outside with my catcher’s mitt. More likely, the quick answer to this question is a resounding “NO”. Few circumstances would lead someone to literally throw millions of dollars out the window, down the drain, etc. Not a million dollars, not in a million years.
What about companies that, effectively, waste millions of dollars trying to implement identity management?
The sad reality is that many organizations trying to implement identity management do just that – waste big money – on the wrong technology, or even on the right technology that sits idle because it can’t be used as designed. Worse, some organizations look to even more technology to “fix the shortcomings” of their selected product. The end result is the identity management version of Frankenstein’s monster.
If you peruse the latest identity management articles from your favorite research company, you’ll find the same discussions over and over: How do we justify the cost? Why do so many companies stop at “single sign-on”? Why do implementations take so long? Why do implementations get halted mid-effort? What’s the true benefit of identity management? What’s the ROI? You’ll also find the same tired answers – whether in printed form, or at one of the many IAM conferences across the country: IAM saves costs at the help desk. IAM can help with audit. IAM can reduce headcount in your access services department. Companies bite off more than they can chew, ROI takes too long, so they give up.
But what does it all mean?
Are we really doomed to these behemoth infrastructures that sit largely un-used, while we pay off consulting and software bills that often run into the millions (if not tens of millions)?
No, we’re not.
IAM is not a lost cause. It can lead to lower costs, easier audit processes, and a demonstrated postive return on investment (ROI). But it takes time – and discipline. As with many aspects of security, identity management is not about technology – it’s about people and process. The technologies are out there, and getting ever-more mature. But, IAM is NOT a Mac or an iPhone – you don’t just turn it on and it magically works. There is a lot of configuration and even custom development that needs to be done after you install your product suite of choice. Even before that, there is a TON of data cleanup, data modeling, and process design that needs to take place, and that is at the heart of this series:
Identity Management in 13 Easy Steps
Of course, the series title is a bit tongue-in-cheek. There’s nothing particularly easy about identity management. Then again, it’s not rocket science, either. It just takes a little thought and a lot of tedious effort – and did I mention discipline? The focus of this series is all on process and data. In fact, product selection is saved until the very last article. That’s right – if you can keep your instant-gratification urges at bay, I recommend that you don’t even bother buying anything until you’re ready to use it. Why spend all that money on a fancy technology if it’s going to sit there, idle, while you beat your head against the wall trying to clean up the data and processes that it needs to function?
An identity management implementation will only be as good as the data and processes feeding it, and that’s the problem many companies face today – most organizations buy a product and figure out after the fact that they have a ton of work to do to make it function. As a result, there is such a lag between the time of purchase and the time of ROI, most management teams lose patience and halt the effort. If you pave the way to implementation by first cleaning house, when you implement the technology its benefit will be seen quickly, which will encourage management to keep it going and try more.
There’s another critical aspect to this approach: gaining the needed experience to properly document requirements. Identity management is extremely complex. No one can just walk in and “get it” in one sitting. Even if the high-level concepts seem obvious, you have to live with the dirty details for a while to really understand the needs of your particular situation. The better that understanding, the better the requirements. The better the requirements, the better the product selection. Choose the right product, and you avoid tossing millions out the window.
Are you ready for this journey? If so, let’s get started. Here is the series I have planned – one article per month. This may not seem like much, but unless your implementation will have a very small user base, it will take longer than a month to execute most of these steps anyway. Of course, the series may change along the way – I’m already concerned about the volume of information I’m trying to fit into some of the articles. I may find as we go that a few of these topics will require multi-part articles. We’ll deal with that when it arises.
For now, here’s the intended schedule:
December 2009: Identity Management 101 – an overview of the different components of an IAM suite, to make sure we’re all on the same page and speaking the same language.
January 2010: Identifying Systems Integrations – not all systems will integrate (directly or indirectly) with IAM. Determine which ones will feed the priority list for the data cleanups and process work.
February 2010: Data Cleanup Part 1 – before your identity management system can work, it needs to be populated with all userIDs, and those IDs have to be clean. The first cleanup is focused on the primary IDs such as AD/LDAP and other key systems.
March 2010: Data Cleanup Part 2 – a key benefit of identity management is the ability to link userIDs in multiple formats from a variety of systems to the user’s primary record. The second cleanup focuses on identifying which IDs belong to which users in preparation for proper linking.
April 2010: Preparing for Password Self-Service – password self-service is a key cost savings of IAM, but it’s harder than you might think. This article will help you prepare your policies and your users for the technology to come.
May 2010: HR as a Source of Record – the HR system is a primary source of record for employees. It can also be one of the primary sources of errors and limitations for identity management. This article will explain the issues that most companies experience when interfacing with HR technologies (and departments).
June 2010: Role- and Rule-Basing – in order for auto-provisioning and -deprovisioning to work, the roles and rules need to be defined. This article will teach you how to avoid turning this effort into a rat’s nest.
July 2010: Role Hierarchies – workflows cannot be enabled without proper approval processes. But approvers aren’t always line managers. This article describes the various role hierarchies that should be established, and the synergies that can be achieved between identity management and other sources of record (e.g., financial systems).
August 2010: Workflows – workflows are the key to automating many processes. This article discusses the considerations in setting up workflows to ensure that they function effectively.
September 2010: Termination and Transfer Gotchas – terminations and transfers are key control activities that are of great interest to auditors. Getting this right in identity management will save everyone a lot of work. Getting it wrong can be disastrous. Learn the pitfalls in this article.
October 2010: Password Self-Service – whereas the April article deals with the foundational aspects of password self-service, this article deals more with the implementation aspects: how to select challenge questions that make sense, exposing PSS outside of the corporate network, etc.
November 2010: Effective Business Cases – now that your house is in order and you have almost a year’s experience with your organization’s circumstances, it’s time to build a business case to buy a product. This article explores a number of value-added functions of identity management that will intrigue your management and encourage them to allocate budget.
December 2010: Requirements and Product Selection – you’ve cleaned your data, defined your processes, and secured a budget. It’s finally time to pick a product. This article will help you document and prioritize detailed requirements based on a year’s experience in the trenches, so that you can make the best product decision possible.
FTC Says Bloggers Must Disclose Freebies
by Aaron Titus
The FTC recently announced new guidelines requiring bloggers to disclose when they get freebies in exchange for reviews. Adopted by a vote of 4-0, this is the first update of the FTC’s Guides Concerning the Use of Endorsements and Testimonials in Advertising in 29 years. The rules go into effect on December 1, 2009.
Securing the Toughest Times
by Ron Woerner
Whether you call it lay-offs, downsizing, rightsizing, redundancies, a reduction in force, or whatever, a reduction in staff stinks. Downturns in the economy often translate to a reduced volume of business, resulting in a correlated reduction in staff. One of the hardest jobs in Security is ensuring that those who are asked to leave no longer have access to the organization’s resources. This is especially hard when you know those affected. However it’s critical that this tough job be done.
The last thing you want or need is for an ex-employee to perform a malicious act as part of their departure. The recent case with the Fannie Mae consultant is a great example of how a malcontent could potentially cause your organization grave damage. Luckily, the Fannie Mae sys admin found the malicious script.
You shouldn’t depend on luck to protect your organization’s critical infrastructure during lay-offs. This article contains concrete steps for you to consider before, during, and after the dreaded layoffs. [Note: the critical nature of these steps is, in actuality, job security for those who need to perform them. Maybe you can use them to justify your job and keep it off of the “chopping block.”]
Before the announcement
Just as in any project (and this is a project), planning and coordination are key. Those managing or initiating the lay-offs (e.g., Human Resources) must have Security on-board early in the process. Delays increase risk to the organization. While secrecy is necessary to protect the process, trusted relationships must be established between all involved, including HR, Security, Legal, and Management. Security needs to know who is affected in order to know what needs to be protected. Security can also help properly protect the “list” prior to the official announcement.
Security personnel (both physical and information) need to ensure the protection of personnel and assets during the lay-offs. On the physical side, you need to make sure that those announcing the lay-offs are protected should the employee(s) get upset or abusive. Security officers should be trained and ready to handle potential conflicts and workplace violence.
Information security personnel should identify single points of (security) failure and high risk areas. This includes administrators with expanded ability, authority or access. Security should also determine if there are any single points of failure in the operations that would be affected by the lay-offs. Management should address these critical points well before the announcement to prevent any unexpected denials of service.
Security personnel also need to develop processes to remove both physical and logical access as soon as the notification takes place. This cannot occur too soon before the associate is notified, or else it might alert the associate, resulting in unexpected consequences. (No one likes to find out that their position is eliminated by having their network or badge access disabled.) Also, this cannot occur too long afterward, for obvious security reasons. Ensuring the correct timing requires pre-planning.
As soon as the announcement is made that your organization is considering lay-offs, extend your monitoring efforts. This could be before the actual lay-offs. Rumors can spread, and associates might take these rumors as reason to start their preparation should their name be on “the list.” Your efforts should include Data Leakage Protection (DLP) to ensure associates aren’t shipping critical company information (e.g., customer lists, intellectual property, or company employee data) to themselves or others. This could occur on the network or off. It’s very easy for an associate to sneak a USB drive filled with an encyclopedia of company data out the door. You also need to be cognizant of physical theft.
During the announcement
With your planning complete, it is now time to enact and follow those processes. As soon as the associate is told that he or she is no longer employed by the organization, you need to disable the physical badge, logical network, and phone access. The accounts should not be deleted, only disabled in case you need them in the future (e.g., rehires). It’s important that all access is also disabled for networks or assets that are externally accessible (e.g., VPN). The time required for this activity will multiply if IT hasn’t kept complete documentation of each worker’s individual access rights, passwords, user names, and security cards.
Occasionally, the manager will request that the separated associate’s email, phone, or voicemail remain available. This is to maintain contact with clients or customers. Security needs to have an exception process in place to handle these requests while making sure the separated employee no longer has access. It needs to be reassigned to the responsible manager or his/her delegate. Allowing permanent access is not a good idea. There should be a set timeframe for this access to remain active before it is disabled.
Also, consider any shared accounts used by the separating employees. Do they know the UNIX root or Windows administrator password? Whether it’s that or any other password for a service account, make sure the password is changed ASAP.
Physical security personnel need to be watching and ready in case the affected people become upset. Normally, you don’t need a physical security presence to escort them. That can be accomplished by the manager and/or HR representative. However, Security should be ready in case things turn ugly. Additionally, they should be watching what property is leaving.
Part of your process should include the retrieval of any assets used by or assigned to the separating employee. This includes: Computers (laptops), USB drives, two-factor authentication tokens, cell phones / PDAs / pagers, and paper documents. When the employee is notified, the manager and HR representative should retrieve these items along with any other property of the organization. Of course, the employee should be allowed to pack up personal belongings, but corporate assets should remain.
Lastly, while the separations occur, continue to monitor online access and activities. You never know the mindset or attitude of those who depart. The potential for malicious acts is increased, especially against any resources that can be seen from the outside (external web sites). Your IDS/IPS should be watching those external network assets and you should be ready to take action.
After the separations
While the major threat may have passed when the laid-off employees have left, it is not completely gone. There are specific post-separation activities that need to occur to ensure risks stay low.
One of the most critical activities is the inspection of online and paper files left behind by the employee. Each manager is responsible for making sure this occurs, because he or she is in the best position to know what is and is not needed. This can be time consuming and tedious, but it can’t be ignored. The benefit is the freeing of storage space.
The manager or their delegate needs to inspect each piece to determine its disposition and whether or not it is still needed for the business. This person also needs to determine the retention period for any material that needs to be kept. This may require collaboration with the legal or compliance department as this material can be recalled for legal proceedings.
Another post-separation activity is inspecting online files for potentially malicious content. This is especially important for any systems administrators who were let go. There have been many stories of sysadmins leaving backdoors, Trojan horses, and time or logic bombs behind. Remaining sysadmins need to inspect any scripts created by the associates along with any scheduled jobs. Failure to take this step could be devastating for the firm.
Lastly, use this time to document what went right during the process and where you have room for improvement. Take time to learn from the experience and enhance the process.
Conclusion
Staff reductions are a part of corporate life. As painful as they are, they are often critical to keep the organization functioning at full capacity. Security needs to be an active participant in the lay-off process to ensure the risks are kept low. The removal of access is only one of the many areas requiring the attention of Security. They also need to be actively monitoring both the physical and on-line activities of the separating associates. This isn’t to be intrusive, but to ensure the continual protection of the organization.
Having a positive security model with validation and enforcement provides a deterrent to malicious behavior as well as the tools to quickly indentify and contain threats when needed. A positive security model includes: policies, procedures, detective and preventative technology, and proactive monitoring. The tips in this article will aid you in the development of your security model so you are ready when the time comes.
Checklist of Security Items to Consider with Lay-Offs
Before
Planning / Establish processes
Disabling access
Communications
Establish trusted contacts
HR
Legal
Security
Management
Identify single points of (security) failure
Employees who pose a danger (to themselves or others)
Administrators
Associates with access to sensitive or confidential data
Identify risks
Intellectual property
Confidential data
Property
During
Disable regular individual access
Logical
Physical
Phone
Email
Remove access to shared accounts
Administrator accounts
Service accounts
Other shared passwords
Asset retrieval
Computers (laptops)
USB drives
2 Factor authentication
Cell phones / PDAs / pagers
Paper documents
Enhance monitoring
IDS/IPS
Logs
Physical surveillance
After
Continued vigilance
Review of assets “left behind”
Online documents, files, and shared storage
eMail
Papers
Check for backdoors, Trojan horses, logic bombs
Unix
Windows
Databases
Network devices
Lesson’s learned
What went right?
What could be done better?
Process improvements
Have a workable plan, or else…
by Martin Fisher
As we continue to discuss the Basic Truths of Incident Response Leadership, we’ve briefly gone over the three Basic Truths as well as done a deeper analysis of “Succeeding By Planning to Fail”. This brings us to:
Basic Truth #2: Have A Workable Plan, or Else
As an Incident Response Leader, one of the most valuable parts of your role is to create, test, exercise, and (when called upon) execute Incident Response Plans (IRPs). IRPs run the gamut from a Post-It note on the wall listing contact phone numbers, to plans that take up several 3-ring binders on a shelf somewhere. Plans can be long or short, detailed or vague, paper or electronic, automated or manual…you get the picture. What makes a good plan different from a not-so-good plan can be summed up in a few ways.
First, can you execute the plan using only the resources that you legitimately would have access to during the incident? We’ve all seen plans that call for using network analyzers that aren’t accessible to the organization or that call for numbers of personnel that just don’t exist. You may have written plans that assume that the responding team has skills and experience that your current team just doesn’t have (I have). The key is to map out the current skills and capabilities of your team and employ them as best you can to meet the anticipated incident.
As you identify resources available to you, it pays to be creative. Can other teams identify folks who could temporarily be available during an incident (think of it as an in-house “volunteer fire department”)? Do you have relationships with designated outside incident response consultants? Do you have relationships with local, state, or federal law enforcement? In today’s business environment, Incident Response Leaders need to be creative in identifying resources that can assist during a response cycle.
Second, you have to test the plan. This sounds so intuitive, but many plans never get past the written-down stage before they are needed in an incident, because no leader stepped in to ensure that the plan would work as designed. One of the most effective testing plans for an IRP is also the least expensive – the simple “Talk Through”, where all of the designated players sit at a conference table (pizza is optional, but highly recommended) and talk through the plan, noting any foreseen problems or issues. The team needs to be encouraged to not only point out potential problems, but brainstorm solutions they can implement as-is since (as we talked about in Basic Truth #1) you can only plan on the resources you have, not the resources you want to have.
Plan testing needs to be redone each and every time the plan is modified, or at some regular interval (at least annually). Testing can be announced or (my personal favorite) unannounced. The time spent testing can help the Incident Response Leader assess not only the plan, but the team assigned to execute it. The feedback loop should encompass applications, hardware, processes and procedures, as well as people. Everything is fair game.
Lastly, you need to continually exercise your plan. This, while not as intuitive as testing, is something that many organizations fail to do, claiming “it’s too hard” or “it’s too disruptive” or “it’s already been tested, why should I do an exercise?” Having performed incident response on plans that have been exercised and plans that have not, I can tell you with complete assurance that plans that have been exercised are executed more smoothly, with fewer problems and a better resolution.
Exercises can range from a talk-through (similar to testing but without the constant feedback loop) to a full-on exercise using live equipment. Talk-through exercises can help in quickly familiarizing a team with a new (or newly updated) plan. Talk-through work will also quickly point out assumptions that, while seemingly accurate in testing, don’t fit the way the incident response team works. All other things being equal, I believe that talk-through exercises offer the highest return for time spent in any aspect of prepping for a incident.
Full-on exercises, as powerful and complete as they are, can be very hard to accomplish. Most organizations cannot fully replicate their production systems (even using virtual machines). These exercises, when they can be done at all, are usually done in development or test environments and generate most of their value by allowing teams to actually assess and interpret adversary actions and data. These exercises are an Incident Response Leader’s best chance to simulate the stress and activity of a real incident.
Taking all of this into account, it’s clear that the Incident Response Leader must be able to create, test, and exercise an IRP to be able to effectively respond during the inevitable incident. By creating plans designed around available resources, qualifying the plans with testing, and regularly exercising the plan, you can ensure that you and your organization will be ready when the inevitable incident occurs.
But it’s not over yet. Once you’ve gotten this far you still have one vital task to accomplish. We’ll cover that in the last article on the Basic Truths of Incident Response Leadership.
Shooting ourselves in the foot: Can the bad economy keep us from buying more bullets?
by Ioana Justus
My career has now spanned almost 12 years, and it still amazes me how so many managers and executives consistently make bad decisions and then are surprised by the results. As the economy has gone bad, you’d think that people would be a little more judicious about how they spend the small budget they have remaining, but that’s turning out not to be the case. Surprisingly, I think the vehemence with which we’re shooting ourselves in the foot has increased as the budgets have shrunk. Now that the economy has bottomed out and is (supposedly) on the rebound, is there any chance of changing some of the behaviors before the upswing takes hold?
Let me ask you a different question: If you lived in Chicago and your house needed a new roof, would you just go out and buy the one recommended by your buddy out in San Francisco, because he’s thrilled with his new roof? Hopefully, the answer to this is no. You may take a look at it, but I’d hope that you would confirm that the structural integrity is insufficient for the added wind, cold, and snow weight that Chicago roofs experience. Once selected, would you allow the contractor to cut corners on your roof installation just to make a specific deadline? Is a permanently leaky roof worth a couple of weeks?
If you wouldn’t blindly purchase something for your own home based solely on the recommendation of a friend, why would you purchase a product for your company based on the recommendation from a vendor, a colleague in another industry, or a conversation on the golf course? How can you justify the potential risk? What happens to your reputation when the product in question doesn’t perform as expected? Where does the budget come from if you end up having to replace the entire thing?
When budgets are tight, there are better things to purchase with what little you have than bullets for your foot, and there are three very simple rules that can keep your munitions purchases at bay:
- Don’t ‘ decide’ on a due date, calculate it. Implementations take time and resources. As much as you might want something in production by the end of the quarter, it might not be possible to do in a reasonable way. Before committing to a date that’s just not feasible, spend a little time to determine the effort involved and lead-times for any purchases/installations that may need to be made, and to assess the availability of the resources required. Then calculate a plausible due date based on the reality of the work effort and be sure to document the consequences of cutting corners, should that still be desired. Sure, there will be instances when time is of the essence, but those are not as frequent as most people think. When you consider long-term support costs and the massive adjustments that are usually needed to make a quickly installed product work, the calculated ROI is rarely met, and the costs to reputation and morale are higher than many would like to admit.
- Don’t ‘make up’ budget numbers, calculate them. We all instinctively have assumptions about how much something should cost. Some of us are better than others at guesstimating accurately. Most of us underestimate – significantly! So before publishing a number that just doesn’t make sense, do the math. There’s truly nothing to be gained by setting the expectation that the desired work can be done for half the actual cost. If the true cost is prohibitive, then the negotiations need to start, and the consequences should be documented and accepted for each item cut. But if you’ve dug yourself a hole before the negotiations have even started, you’re in for a world of hurt.
- Don’t fit your problems to a pre-determined solution, pick a solution that fits your problem. No matter how nice the vendor is or how much you value your golf buddy’s opinion, the product they’re pushing may not be the right one for your company. The only way to know for sure is to gather requirements first, based on the actual needs, desires, and roadblocks currently being faced by your company. Then you can assess whether the desired product fits the bill. If it doesn’t, don’t buy it! If nothing fits the bill, pick the best option, or consider waiting for future developments. In any case, be sure to document the trade-offs, and get agreement that they’re acceptable.
Simple, right? 
But if we were all doing this, I wouldn’t be writing about it. The problem is that it has become acceptable to ignore the rules, and anyone who doesn’t follow suit is viewed negatively. The real challenge is for each of us to take the personal responsibility to follow the rules, regardless of our position in the company. Only then will we change the expectation and make it unacceptable to ignore the rules.
Policies don’t have to be painful
by James Costello
Several years ago, one of my clients asked me to write a security policy for them (since I was the “Security Guy” at the consulting company they employed). I spent a couple of hours looking at various templates and examples on the Internet. What I found were a lot of carbon copies of the same few templates with “insert corporate name here”. Regardless, I created a security document for them; my client was happy to have something and I was able to help them out, but I was not really satisfied with what I had written and wanted to do better.
Recently, I’ve been working with a team to rewrite the security policies for my current employer; policies that look exactly like the one I put together for my client years ago. The review of the current documents made something clear to me: No one likes to write these documents, so they use templates as a quick way to get the job done. Unfortunately, the template-based policies can be difficult to read through for people who need to work on them, and will most likely be unread by the employees who will be most affected by them.
So what can we do, dear reader?
I am going to start by defining policy this way: A policy is a set of rules that supports an overall vision. This policy is developed using a set of standards, which are incorporated into procedures to implement the policy. For example, if the concept is that the company’s wireless network should be secure, the policy would state that technologies will be used to secure wireless communications on corporate sites. The standard would be that the general public would not be able to connect directly to the corporate network via wireless networking. The procedure would be to use WPA2 configured on the access points. If a new technology comes out that proves to be more secure than WPA2, the policy does not need to be rewritten; just the procedure. There can also be multiple procedures for the same policy, e.g. the procedure to implement WPA2 on Windows is different from the procedure to implement it on Linux.
It’s simple: The vision is the overall goal. The policy supports the vision, the standards measure how the policy relates to the vision, and the procedures support the policy. Procedures should not typically be included in a policy document because they can be more dynamic and will change more often than the policy will. In my current organization, policies have to be approved by the Executive Management team, and it can take as long as a month for one sentence to be approved. Instead, procedures should be established at the team level and reviewed by direct management, so that changes to the procedure can be implemented quickly while still supporting the existing policy.
One of the best references I have found for this policy style are the PCI-DSS documents. Vision, policy, and standard are established, and the procedures are left up to the individual companies. The documents are easy to read and reference, and can be a great starting point for companies to examine how their own security policies are written. Not everything in the PCI-DSS documents will be applicable to every organization and I do not necessarily agree with everything in them, but they are quite useful for readability and review by non-IT security staff.
The simple steps to follow to build your own company’s security policy:
- Establish the vision.
- Write the policy to support the vision.
- Develop standards to measure the policy, and finally
- Create the procedures to implement the policy
You are now Liable for Unintentional Medical Data Breach In NY State
by Patrick Romero
Health care employers be warned – an unintentional data breach could now cost you much more than you imagined. A New York State Appellate Court has recently upheld a $365,000 jury award against a health care center that mistakenly disclosed information regarding a patient’s medical information.
A young, unmarried woman who lived with her strict Roman Catholic parents decided to terminate her pregnancy at Long Island Surgi-Center. She gave instructions to Surgi-Center never to call her at home despite providing them with her home telephone number on questionnaire forms. A day after the procedure, a nurse called the number provided to inquire about her condition and to confirm that she had no subsequent medical complications. Unfortunately, the nurse spoke with the woman’s mother and revealed sufficient information to allow the mother to conclude that her daughter had an abortion.
In a 3-2 decision, the Court held that the plaintiff be awarded punitive damages for an unintentional breach of confidential medical information even if there was no malice or malicious behavior by the defendant. As a result, the 2nd Department of New York has expanded the scope of punitive damages to include unintentional medical disclosure regardless of whether the act was done in good-faith.
The case is significant due to the implications for organizations handling medical information. Even though the medical center’s actions were not malicious, intentional or done in bad faith, disclosing the plaintiff’s medical information was grossly negligent and wanton behavior. Based on this interpretation, it appears that it will now be more difficult for healthcare workers to justify disclosure of medical information on mistakes or negligence.
The Court also appeared to have affirmed the jury’s award for punitive damages in order to send a message about the importance of protecting medical information. Punitive damages are seen as a way for the judiciary to espouse a particular public policy and to deter future violations. The Court here is clearly concerned with instances of wrongful medical disclosure and shows itself to be in sync with state and federal legislative efforts to protect confidential information. The opinion does not discuss violations of federal privacy laws such as the Health Insurance Portability and Accountability Act (HIPPA). However, it does mention New York legislation pertaining to the rights of patients in medical facilities like the one visited by the plaintiff.
More and more states are enacting laws regulating the disclosure of private and confidential information. Court cases like this highlight the need for companies to enact strong compliance rules that clearly describe the conditions in which data can be disclosed. These rules need to be properly followed and understood by all employees of an organization. The decision in New York should highlight the fact that even inadvertent medical disclosure can now lead to serious liabilities issues.
Do Data-Breach Laws Give You The Power to Hold Corporations Liable?
By Michael Santarcangelo and Patrick Romero
There are roughly 40 states that have some sort of “data-breach” law or bill being considered that force notification of a company’s security breach (or suspected breach) to their consumers. These laws were enacted as a way to force companies to disclose the possibility that individuals personal information was compromised and that they could potentially become victims of identity theft.
Over the coming months, we’ll spend some time exploring how the different states are handling these statutes. When you peel the layers back a bit, and consider them from different angles, we can learn some interesting elements – useful to us from individual and organizational perspectives.
Even with these new laws in effect, it seems that there is little a person can due to hold a company liable for a data-breach based on their weak security standards. Recently, state governments have begun to change this by imposing liability on the retail business and others, thereby opening the door for consumers to sue companies that do not adequately protect the personal information that they collect.
This is a serious issue that has implications for everyone involved – and ultimately requires clear definitions, mutual understanding and will take years to sort through. In the meantime, we’re going to ignite our series of articles exploring these laws and developments by analyzing some recent events.
Minnesota PCI Legislation
Effective August 1st 2007, Minnesota became the first state to require that all companies handling credit and debit card data comply with the Payment Card Industry (PCI) data security standard (in a future article or podcast, we’ll explore and debate the value of tying the PCI standard to the legislation – Michael).
The state’s new Plastic Card Security Act would prohibit a company from retaining a credit card’s security code data, the PIN verification code number, or the full contents of any track of magnetic strip data. The new legislation is intended to target retailers who continue to store data in violation of PCI standards. The bill also makes it a violation for retailers to a credit card holder’s PIN number longer than 48 hours after authorization of their transaction. Similar bills are pending in Texas, Illinois, Connecticut, and Massachusetts.
The significant of this legislation is important in light of recent ruling by courts that have dismissed class action suits against companies following data-breaches. On August 23, 2007, the US Court of Appeals for the 7th Circuit held that identity-theft monitoring costs paid for by the plaintiffs were not compensable damages under Indian’s security breach notification statute. In Pisciotta v. Old Nat’l Bancorp, the court held that there was no state statute supporting the compensation of incurred costs because “had the Indiana legislature intended that a cause of action should be available against a database owners for failing to protect adequately personal information, we believe it would have made some more definite statement of that intent.” So for the time being, unless you have an actual showing of harm as a victim of identity theft, potential harm will not suffice.
Consequences for the Courts
As more states begin to enact legislation that requires companies to comply with PCI, courts may begin to allow litigants to be compensated as a result of a security break. The argument that courts have made in cases like Pisciotta will clearly be much weaker as states legislatures conspicuously demonstrate their intent to punish companies by enacting specific statutes targeting the security of personal information.
Federal and state courts will feel much more comfortable in their decision to expand their legal theories of liability when supported by statutes that explicitly creates private actions for security breaches. In this context, it is much more likely that Courts will not follow the ruling in Pisciotta until after states pass legislation similar to Minnesota. In other addition, plaintiffs might also receive some relief if a recent bipartisan bill in the U.S. Senate gets passed. The bill, known as the Identity Theft Enforcement and Restitution Act of 2007, was introduced on October 16, 2007 and would give victims the ability to seek restitution for the loss of time and money as a result of identity theft. Such federal legislation could prove to be effective in jurisdictions with no state identity-theft laws.
Consequences for Businesses
Meanwhile, the retail lobby continues to argue against laws that would hold them liable by arguing that these laws would be too costly and burdensome, especially for small businesses. This apparently was the argument that convinced Governor Schwarnenegger to veto a California law that would have mandated the retail industry comply with PCI requirements. While this may be true, legislation in Minnesota limits this burden by exempting businesses with few than 20,000 transactions from their statute. Clearly, there is a way for the legislature of any state to write a statute that can pressure companies to improve their data security standards without crippling small business owners.
While the retail industry will continue to resist such legislation, there is strong support from banks and credit unions, since in the eyes of consumers they often blamed for such breaches. TJX is currently being sued by several banks
who seek compensation for having to re-issue credit cards and credit monitoring to thousands of their customers as a result of a massive security breach earlier this year. Depending on how the case turns out, the burdens and cost of breaches will shift away from consumers, banks, and credit unions but will perhaps be shared by the retailers and others (of course, the consumer pays in the end).
Preparing for the change
As a consequence of new state and federal legislation, the landscape of data security will continue to evolve, sometimes in seemingly dramatic fashion. Individuals and businesses will most likely be able to get their day in court for incurred damages a result of security breaches by a third-party. Industries that have for now been able to get away with having minimum security standards will begin to take notice of their potential liability and hopefully, will improve the way they guard information. While the process is slow, it appears to be inevitable.
This isn’t doom and gloom.
Many of us have already begun to prepare for these changes by improving and writing security policies that make sense and can be understood, improving the process of protecting information and working to involve users in solution through training and awareness. Focus on the fundamentals of information protection and you’ll be less likely to be the test case.
Engage with Michael
-
Journey Into the Breach
