Tom Olzak

Posts Tagged ‘process’

Government Dysfunction Strikes Another Blow for Insecurity

In Access Controls, Business Continuity, China, Cyber Espionage, Government, Hacking, Network Security, Password Management, Policies and Processes, Risk Management, Security Management, Vendor Management on October 12, 2010 at 12:51

For many years, even before the Internet, changing default access codes, passwords, and other vendor assigned information was considered a basic no-brainer.  And I understand normal people (non-IT) not getting it.  After all, if it wasn’t a good password, why would a vendor assign it…?  And who wants to argue with a support guy on the phone who can’t understand why you changed it?  I get it.  However, when our government doesn’t see the value in the change, we have a big problem.

According to an article last week in the New York Times,

[University of Michigan researchers] infiltrated the District of Columbia’s online voting system last week. They changed all votes for mayor to Master Control Pro and elected HAL 9000 the council chairman. The blaring University of Michigan fight song played whenever a new ballot was successfully cast” (Wheaton, 8 Oct 2010).

To be fair, this is a pilot project by the District’s Board of Elections.  However, I always thought “pilot’” meant seeing how it works in the real world.  So it should also mean setting security for testing system trust.  One reason why this is necessary was included in the same article:

“[Professor J. Alex Halderman] said he also saw signs that computer users in Iran and China were trying to crack the system’s master password — which his team obtained from an equipment manual. (Network administrators had never changed the four-character default password.) He said that the foreign hackers were probably not specifically trying to break into the District’s voting system, but that they represented a threat nonetheless” (ibid.)

In addition to immediate attempts by our “enemies” to hack into the system, we decided to practice global good will by leaving the vendor password in place for anyone who wanted into our system.  What a novel idea regarding how to meet the cyber-crime and warfare challenges we increasingly face.

In case you haven’t yet gotten the message across to your network engineers or internal support personnel, this might be something you can use as an attention-getter (instead of the bat you’ve placed strategically next to your filing cabinet.

This is just one more example of the dysfunction of our government information handling capability.

Protecting core productivity apps with EMET

In Uncategorized on October 29, 2009 at 11:02

This week Microsoft released a toolkit designed to help IT professionals protect systems from common threats.  Named the Enhanced Mitigation Evaluation Toolkit (EMET), this little gem is easy to implement, once you install the very small executables on your workstations.

Before I walk you through setting up FireFox, I want to take a minute to tell you why you should care about this.

Why you should care

In its initial release, EMET protects against exploitation of four common attack vectors.  When an application is “configured,” requisite behavior necessary for an effective compromise of a system is blocked.  The following information is from readme.rtf included in the downloadable EMET .zip file:

  1. SEHOP – Structured exception handling (SEH) chain validation breaks SEH overwrite exploitation techniques.
  2. Dynamic DEP – Certain portions of memory are marked as non-executable.  Using EMET, you can target specific applications instead of fighting with compatibility issues caused by setting DEP in the BIOS.
  3. Null page allocation – Attackers are blocked from taking advantage of NULL dereferences in user mode.
  4. Heap spray allocation – Heap spraying involves filling a process’ heap  with specially crafted content to aid system exploitation.  EMET pre-allocates those memory addresses and blocks these attacks.

Although Microsoft hasn’t testing all possible applications, they have successfully tested the following:

  1. iexplore.exe (IE) – although there are apparently some problems getting IE to behave all the time.
  2. winword.exe (Word)
  3. excel.exe
  4. acrord32.exe (Acrobat Reader)
  5. firefox.exe
  6. outlook.exe
  7. powerpnt.exe

The developers of EMET warn it isn’t for everyone.  Since EMET turns off functionality some applications may need to work as expected, it should only be used by IT personnel willing and able to work through possible issues.

Using EMET

Using EMET starts with a quick download of a .zip file.  Extract the file in a folder not generally accessible.  This helps prevent unwanted visitors to the target system from messing with them.

Once I extracted the files on my Windows 7 Ultimate desktop, I was in such a big hurry to start testing I forgot about my “new enhanced” security.  EMET is run from a command prompt and requires elevated privileges.  So my initial run was thwarted until I performed the following steps to bring up a command line window with the proper permissions:

  1. Click Start
  2. Type Command Prompt in the search field.
  3. Right click on Command Prompt at the top of the programs list to bring up the window shown below.


    Figure 1

  4. Click Run as administrator

I then followed the simple example in the readme document to protect FireFox, as shown in Figure 2.



Figure 2

Pressing Enter resulting in a successful run of EMET.  I confirmed this by listing all protected applications.  See Figure 3.


Figure 3

That’s all there is to it.  EMET works with

  • 32-bit Windows XP, Server 2003, Server 2008, Vista and Windows 7
  • 64-bit Vista, Windows 7 and Windows 2008 R2

Beware Regulatory Hysteria

In Data Security, Government, HIPAA, Policies and Processes, Privacy on June 13, 2009 at 09:18

Regulatory Hysteria: Knee-jerk overreaction to new regulations, often placing individual privacy at risk.

For years, since before HIPAA and SOX, organizations have often overreacted to government mandates.  Some of the blame falls on accountants and security consultants who don’t understand the law, are trying to make a few extra bucks, or are simply covering their own butts. In other cases, organizations simply suffer from what I call regulatory hysteria.  Whatever the reason, overreacting to regulatory requirements can sometimes put customers and employees at greater risk.

Sherri Davidoff writes about a recent incident in which she appears to have been personally involved.  The post, located at, describes the results of the FACTA and its Red Flag Rules on patient privacy.

Sherri was apparently confronted with a notice of a new requirement to produce a photo ID when she visited her doctor.  Since she didn’t have one, the office staff wouldn’t process her for her appointment.  While she stood there, Sherri observed staff scanning patient driver’s licenses for filing in their computer system.  Sherri was upset that she was inconvenienced and about her doctor demanding additional personal information.  Was she justified?  Maybe.

First, the Red Flag Rules are designed to protect us from criminals who seek to steal our identities for financial gain, including using our health insurance.  Health insurance theft is a big problem and growing.  The rules also help ensure someone can’t receive care under your name and have those results placed in your records, with the possible result of you receiving harmful care based on invalid assumptions about your health.  They are a good idea, and Sherri should simply get a photo ID—although there are other ways to verify identity, and the doctor might try to be a little more flexible.

Scanning of licenses or other photo IDs, however, is another matter.  There is no requirement to scan and store proof of identity.  The requirement is to demonstrate documented processes to:

  • Verify a potential patient’s identity
  • Report possible identity theft

This particular case looks like butt-covering rather than reasonable and appropriate compliance with the law.  And even if Sherri did produce a photo ID, how much effort is actually taken by the office staff to verify the ID itself?  What training did the staff receive to help them identify fraudulent documents?  Do they even compare the photo—I mean actually look at it—with the person standing in the reception window?  These are more important considerations than getting a scanned copy of a photo ID.  Finally, does the office staff simply accept verbal confirmation of identity for future visits once a scanned ID is in the system?  I hope their scanner is better than most, or picture quality will be close to worthless.

The other issue Sherri wrote about was her concern about the office potentially storing additional information about her in their computer system.  If the office is HIPAA compliant, and ePHI is protected in accordance with the security rule, this shouldn’t be an issue.  If it isn’t, Sherri has bigger problems than not having a photo ID or having an ID scanned.

My problem with Sherri’s visit is different from hers.  There is apparent compliance with the Red Flag Rules.  However, compliance extends far beyond a simple scan of an ID.  If the office manager simply uses the scans as evidence that an ID was produced without requiring trained employees to follow an actual identity verification process, then there is no compliance—just the appearance of compliance.  I think Sherri should be more concerned with how the office staff verifies her identity during each visit, and whether they are actually compliant with the HIPAA security rule, than whether they require a photo ID.

Written Policy without Process and Oversight is Just Wasted Effort

In Business Continuity, Data Security, Policies and Processes on April 20, 2009 at 12:05

Whether prompted by regulations or by management intent to comply with security best practices, the first step after creating a security strategy is development of policies.  However, there are some organizations who treat policies as the endgame.  Those taking this approach are not only misguided.  They are potentially exposing their sensitive data and critical systems to greater risk.

The Policy Myth

Security policies are simple statements of intent.  They provide to employees management’s expectations regarding acceptable use, handling, and implementation of critical systems as well as the confidentiality, integrity, and availability of sensitive information.  However, they don’t provide for consistent application of management intent.  Nor do they describe and mandate and system of oversight to ensure compliance and effectiveness.

David Aminzade addresses these issues in an article posted today on Help Net Security.  He begins with,

Most large organizations maintain a detailed corporate security policy document that spells out the “dos and don’ts” of information security. Once the policy is in place, the feeling is of having achieved ‘nine-tenths of the law’, that is, that the organization is in effect ‘covered’. This is a dangerous misconception. Because much like in the world of law and order, while creation of law is fundamental, implementation and enforcement of law is what prevents chaos.

Source: Is having a security policy in place really nine-tenths of the law?, David Aminzade, Help Net Security, 20 April 2009

Making Policies Real

To make policies ‘real’ to technical and business process employees, people must be aware they exist.  They must also follow documented processes intended to result in compliance.  So the next step after policy approval is development of supporting processes.

Processes typically provide step-by-step instructions for how to perform a single task or set of tasks.  If an employee follows a process, he or she will automatically produce compliant outcomes—at least that’s the expectation.  Effective processes are developed in collaboration with all stakeholders, and then introduced to existing employees via training programs.  New hires should be provided with similar training.

This is another point in developing a security program where some organizations stop, with the belief they are now compliant.  Stopping here strengthens their defenses beyond those of the policy-only managers, but it still causes them to fall short of a truly effective security program.

The final step in making policies real to employees and the organization is implementation of oversight tools and processes.  Aminzade included a good-start list in his article:

  • Continuously monitor firewall and other security device changes, compare them to the corporate security policy, and send out alerts if the policy has been violated.
  • Track and report all changes in a uniform, simple and straightforward style.
  • Provide a vendor-neutral, top-down view of all security infrastructure that an executive can understand.
  • Enable security administrators to test a change against security policy before it is implemented, to assess and avoid risk.
  • To this list I would add internal audits, which provide an outsider’s perspective of processes and outcomes.  I would also add both internal and external vulnerability scans and penetration tests. 

    The first bullet should be part of an overall log management process.  I always recommended outsourcing this activity.  It is tedious work which can be done at less cost by a managed security services provider (MSSP).

    Tasks associated with the second and fourth bullet are typically part of a change management process.  Change management

    … deals with how changes to the system are managed so they don’t degrade system performance and availability. Change management is especially critical in today’s highly decentralized, network-based environment where users themselves may be applying many changes. A key cause of high cost of ownership is the application of changes by those who don’t fully understand their implications across the operating environment.

    Source: Implement change management with these six steps, Change Tech. Solutions, ZDNet, 8 January 2004

    Along with oversight, sanctions should be imposed fairly, as close to the actual event as possible, and clearly stated as possible consequences for not following approved procedures.  Formal, documented investigations can help change employee behavior even if their risky actions are not cause for disciplinary action.  Investigations help raise management awareness of potential employee or process issues.

    The final word

    Getting compliant is about documenting management intent, building enforceable processes which produce consistent outcomes, and monitoring to ensure the network is as secure as expected.  Assuming employees will simply act safely because a policy exists or making assumptions about security outcomes is a good way to end up as tomorrow’s media target because of a breach or malware induced network shutdown.

    It’s all about business outcomes

    In Business Continuity, Project Management, Risk Management, Security Management on April 13, 2009 at 13:57

    Interesting stuff in a Kaspersky editorial

    Across the variety of orientations which exist within security, outcomes are what counts. Some examples:

    • Compliance officers want to keep the CEO out of jail. All the process in the world is useful because when they’re not, they can talk about their plans for correcting that.
    • Applied Researchers ask “did you pwn it?” They’re concerned with testing a hypothesis, which is “this system resists this type of attack”
    • Law enforcement wants to catch the bad guy (or gal). Much of the friction between civil libertarians and law enforcement comes from a conflict about prioritization of goals.

    We’ve focused on process because we have so little data on outcomes. People will talk about their training processes. But when you ask them, did that process work? no one wants to say.

    Source: Security is about outcomes, not about process, Adam Shostack, 13 April 2009

    Read the rest of this entry »

    %d bloggers like this: