Attacks are no longer simple and scatter gun, like the Nigerian scam. The principle behind this type of attack is launch a hundreds of thousands attacks and hope that just a very few stick. Grammar was poor, yet overall [Click to Read more...]]]> Based on the current attack vectors that are taking place, we need defense teams that are multi-talented.

Attacks are no longer simple and scatter gun, like the Nigerian scam. The principle behind this type of attack is launch a hundreds of thousands attacks and hope that just a very few stick. Grammar was poor, yet overall was and sadly still is very, very effective.

Today we see more highly targeted attacks, emails targeted to specific companies and/or individuals in a company. The classic is a fake email from the CFO “Our upcoming SOX audit and what you need to know, about the company future” What employee is not going to want to click on a similar email with a malware infected PDF. After all how many employees are going to know what the true financial statements will look like?

Even after years of security awareness training, some employees might still click on the Nigerian scam email. However, the malware financial statement, would probably get a very high click rate. After all it is targeted, and from an internal source the CFO.  What is worse, hundreds of organization are going to see the Nigerian scam, and they all will be working on a solution. Whereas, the malware financials, it is only going to be seen by a very few companies.

We need a multi-talented multi-skilled team, capable of monitoring, checking, analyzing the data while in motion. We need a team of Security, Technical, Forensic, Software and Systems experts to work together. Forensic teaches us to hunt, look and analyze and seek answers, learn what did take place. While Security is more focused on what will take place.

Now we need to consider the threats, both actual and perceived. Identify and discuss them, then list cost-effective solutions. In the solutions identify what is needed and possible methods to implement the solution. After all threats have been identified you might find a single solution that will address more than [Click to Read more...]]]> Previous steps

Step 3 : Risk Assessment

Now we need to consider the threats, both actual and perceived. Identify and discuss them, then list cost-effective solutions. In the solutions identify what is needed and possible methods to implement the solution. After all threats have been identified you might find a single solution that will address more than one threat, or might create a new threat.

Look at both internal and external threats, malicious and accidental threats, physical and entirely logical threats. Sadly just defending the perimeter is not enough in today’s security defense structure. If an attacker can gain access to an internal device, locally or remotely, then all perimeter defenses are in effect null and void. We need to protect the border yes, but we also need to protect the internal hosts.

Qualify what is acceptable risk.  Remember all risk can not be avoided, there is going to be residue risk always. How much are we willing to accept, how much are we going to mitigate and how much are we going to transfer?  Too often management who do not truly understand risk want to totally eliminate risk with a minimal budget.   This is not going to happen. Mitigation and transfer have costs, and what you do not mitigate or transfer you are left to deal with or account for.

Step 4 : Resolve Implementation Planning

Now is the time to start planning the repairs or fixes.  First plan, What MUST be done?,  How long will it take to reach this objective?, and What is the measurement to say we were successful? Second account for the fact this is the right method and Lastly budget enough resources Financial, Human, and Time. required to implement the solution.  Hold off the quick draw from the hip and running off and performing the fix immediately.  Look for cross contamination, be aware that some solutions might create or worsen current problems. No solution is self contained, they will have costs and ramifications on other related topics.

Step 5 : Resolve Projects

Now that all solutions have been documented, planned, assessed, justified and budgeted for,  now we can start implementing the solutions.  “Hi Ho Silver, and off to the rescue we go” Be very aware to time lines budget overruns, and ramification effects.

If project 10 relies on project 8, and project 8 is two weeks behind schedule then we simply can NOT expect project 10 to start or complete on time. Make sure that there is one person tasked to monitor the projects and measure the project completion status and budget usage.

Do NOT forget to plan user training especially on the new processes and procedures that have been implemented. Check that the new procedure is in fact being followed and not old habits.  Review and update all policies, procedures and rules to account for the solutions, and train.   Too often we just expect others to follow the new procedures and yet they do not know anything about the changes.

Step 6 : Audit review and plan for the next Assessment

CONGRATULATIONS ! ! You have just started !    WHAT ? ? ?

Yes it is time to start the process again. Do not get me wrong,  accept the new changes, reward the improvements. But then re start the next project ensuring that the implementation to the inital findings have been resolved and that in fact the initial list of findings have been reduced.

Neatly close off the current audit. Ensure all steps have been clearly documented and addressed. Plan for the next audit, and monitor that the new policies and procedures are effective.

The planning and scoping of a project is often one of the hardest parts of project management. Audits, like a HIPAA audit, are a targeted project with findings or shortcomings as their project deliverables.  If the audit scope [Click to Read more...]]]> HIPAA audits are just like any audit or project they require the proper steps.

Step 1 : Project Planning

The planning and scoping of a project is often one of the hardest parts of project management. Audits, like a HIPAA audit, are a targeted project with findings or shortcomings as their project deliverables.  If the audit scope is too narrow, then the audit findings will not be an accurate reflection of the organizations status, with regards to HIPAA compliance.  Likewise if the audit scope is too broad then too much time is going to be wasted on insignificant or minor issues.  Key points during any HIPAA audit or project planning step are:

• Understanding the HIPAA Security Rule, what truly is required and needed.
• Identify the HIPAA Security Officer, as they should be the key personnel involved from the start.
• Understand and identify your current resources points

This is a vital step to ensure that all members are on the same page, having auditors and auditees all seeing the same road map, as well as clearly defining the success and failure objectives.

Step 2 : Gap Analysis and System Discovery

Now the HIPAA audit can begin. Always start broad and narrow down as you identify key information points. For example: start with all workstations must be examined. Now, first look for which workstations or devices have and which do not have EPHI (Electronic Protected Health Information). Only then can you progress forward and eliminate those devices which clearly  do NOT have EPHI.  Sadly this simple step is not followed and devices are not examined which have EPHI, often resulting in a HIPAA breach due to poor system discovery methods. Identify and look for nefarious means an outsider would use to gain access, or in other words think like the bad guy.  Think  “IF I wanted to gain access to X’s medical files, how would I do it, as an outsider or non-employee?” Now do NOT go do that!      But,  often this is the exact process the “real”  malicious individual would follow.   Trust me if you can find a weakness, so can they.

This is NOT the time to fix things.  This IS the time to find the problems.  Yes, I know we do not want to, I know we think they do not exist in our organization, I know this can be painful finding problems that you did not realize existed,  and now you realise you may be miles away from the compliance line.  However, you should face them NOW and not later. Do NOT be afraid to double or triple check results to ensure that a system does or does not have EPHI. Be inclusive not minimalistic.

Use a survey and ask do we comply with  “aaa.bbb(c)d” of the HIPAA rules, on a scale of 0 being total non-compliance and 100 being absolutly, verifiable compliance.    At the end anything that does not score above a 20, is a total compliance failure, and anything between 5 and 19 is borderline.

“But that means too much is non-compliance!” you might say.

True, but if the respondents to not know the measuring scale then they will try to duck issues, oh we are a 70 on this issue.  They know full well they are not compliant, but it’s not THAT bad in their mind.  At this point of the audit process this is MISSION CRITICAL.

More steps to follow…..

GOAL 1: The network defined

We need to [Click to Read more...]]]> Most Security regulations like HIPAA, SOX, GLBA and PCI (which is an industry standard Not a regulation),  all call for a risk analysis audit.  To many this is an unknown or difficult process, so I thought I would present the common goals for a Risk-based Analysis Audit

GOAL 1: The network defined

We need to know what is being looked at or reviewed. Things like what devices are there? Is the network segmented? Is there additional controls or filters between different areas? What network areas exist? etc.. This has to be done carefully. Not done right and the whole audit process will be off balance.

GOAL 2: Gather non-technical Information

Ask the staff to complete a questionnaire, three types 1) technical questionnaire for the technical staff , 2) management questionnaire for management staff , and 3) general questionnaire for general staff. You will be amazed that you can ask the same question to all three groups and get more than three responses? Yes hear what technical has to say, but do NOT just accept their answer as fact. This will give you a very good understanding of the corporate climate towards security.

GOAL 3: Assess the boundary

A boundary is obviously the internal to external point. But also include internal boundaries. For example:  if the DMZ is declared it’s own segment on the network check the boundaries between the internal and DMZ and the external and DMZ. If sales is a different segment from marketing, check the boundaries between these also. Protecting the border or boundary between external and internal is NOT enough. Ask yourself what if the attacker gains access inside the border, then what?

GOAL 4: Password strength checks

Check password strengths, check each user has their own unique user name and password. Shout, scream if users share access. There is NO reason whatsoever for users to share access.

GOAL 5: Investigate the devices

Actually check the devices. I remember one audit where the client had previously had problems with their router access, which after a while got resolved by their ISP. The solution, was to simply bypass the firewall and connect straight from the router to the network. Solved their problem!  The firewall was powered and on, but had no traffic going through it. Check for these things.

GOAL 6: Check for wireless

Actually check for wireless, especially if the company policy has a NO wireless allowed policy.  Recently they found just how easy it was to tap into keystrokes from wireless keyboard  (Read Here).  Think about that when we say wireless from now on.  It is amazing how many audits are conducted and at least one rogue (unauthorized) access point is detected or discovered.

GOAL 7: Check actual vs documented firewall rules

Actually read the firewall rules direct from the device(s) and compare them to what is documented they should be. With proper change management there should be NO difference. But, even then you may be surprised.

GOAL 8: Aim, Attack, Fire

Test, test, test.  Actually run a complete penetration test, and vary the type from white , gray to black.  (If you are not sure what this means drop me an email I would love to discuss it further.) Test from the outside and the inside. Not all attacks take place by Mr. Evil from far far away. More often than not, they are local or ex-employees.

GOAL 9: Compare results and review Policies and Procedures

Compare the results from your tests and investigations to what Policy and Procedures actually say.  Policies with NO enforcement are wasted paper.   Procedures not followed are events doomed to failure.

GOAL 10: Lessons learned and improve

Learn!!.  Actually take the results and plan an improvement strategy. It is very seldom that an audit will come back with NO findings. If you have had one let me know, and go back a really conduct a real audit this time. Take the findings big, small or otherwise and plan how to remedy them and get them resolved.

Just a short overview of what should be done when completing a Full Risk based Analysis Audit of any organization’s IT security posture.

My 2c from small town America

“An IT auditor may also work a a forensic specialist (cyberforensic) where the objective is usually directed toward potential crimes or nefarious deeds”

Then let us make lawnmower mechanics,  aviation engineers. Let us have the local lawnmower repair guy service the jet engines to 747s. Obviously we will not!.  [Click to Read more...]]]> Read an article that just blew me away!

“An IT auditor may also work a a forensic specialist (cyberforensic) where the objective is usually directed toward potential crimes or nefarious deeds”

Then let us make lawnmower mechanics,  aviation engineers. Let us have the local lawnmower repair guy service the jet engines to 747s. Obviously we will not!.  Even within the realm of medicine we allow doctors to be brain surgeons and doctors to be spine surgeons. In the medical PROFESSION we don’t expect our podiatrists to operate on our brain.  Why then time and again to we insist within the IT industry to make all IT fields equal.

• Local computer retail and sales stores are now cyber security specialists.
• IT Auditors are forensic investigators.
• Electricians are complex network integrators.

Why?

As both a certified CISA (Certified Information Systems Auditor) and computer science graduate with 15 years pure IT experience, as well as a CISSP and GCIH, who lectures computer forensic at a local college.

Why do we allow technical things to be the domain of everyone.

In all respects to my fellow CISA certified members most are ex financial accountants and auditors, yes there are some that have technical IT backgrounds, but they are few.  just ask any IT Auditor CISA certified or not, to explain the difference between ram slack space and file slack space. Or, explain in detail the system boot process.

Over and over throughout my 15 years of IT one topic or another becomes the “buzz word of the day”, and suddenly everyone is an expert in that area. Unless we as the IT industry act like the other professional industries medical, legal, etc.. we are going to be laughed at, and internally destroy what we are working and stand  for.

Why do companies end up on the data breach list and within months of passing their SOX, PCI, HIPAA, or whatever security audit.  Because security was not truly understood.

My favorite example is a big player in the regional Data Center service market, who insisted a SAS 70 audit was a security audit. My response you want my business put your money where your mouth is and let us test your security. At the time their administrator password was dictionary based and less than 6 characters, and very simple penetration test was over in minutes with access as Administrator on multiple machines. Their response, but they had just passed their SAS 70 audit, and don’t understand why we gained access to easily.

Come On, IT professionals, it is time we stand up as professionals and fight for specialists like the other professional industries.

My 2c from small town America.

So [Click to Read more...]]]> For most medical practitioners the full concept of Disaster Recovery Planning (DRP) is sadly not fully understood.  This often comes from a very weak approach to Risk Management, since the two concepts are very interrelated.  [ By the way: HIPAA does calls for both, Disaster Recovery Plan see 164.308(a)(7)(ii)(B)  and Risk Management see 164.308(a)(1)(ii)(B)  ]

So what is Disaster Recovery Planning?

Disaster recovery planning (DRP) is critical to the success of business continuity, no they are not the same in fact DRP is a part of Business Continuity Planning (BCP). A disaster recovery plan is composed of three phases:

• preparedness,
• response, and
• recovery

[ Cause for failure: ]

Without complete management/owner by-in or commitment, your BCP and DRP are destined for failure. I make this statement up front because too often medical practitioners, do not want to get involved with the process, or do not understand the process. Then sadly when a disaster strikes they start making decisions out of panic, because they do not know or follow the plan.

Also to understand the relationship between Business Continuity and Disaster Recovery, let us look at the overall components of a Business Continuity Plan (perhaps in another blog I’ll talk more about BCPs)

• Risk Assessment
• Impact Study / Analysis
• Recovery Plans / Strategies
• Implementation and Awareness
• Testing or Exercise Strategies
• Make necessary adjustments

Both DRPs and BCPs are cycles: Plan , Decide , Implement , Test , Maintain , Repeat.

The two most commonly seen failure points in the Disaster Recovery Plan cycle are: Testing and Repeat.

[ Key to Success: ]

Many organizations run through the plan once and stop after Implementation. Preparedness is key to surviving any disaster. Depending on the sources between 40% to 60% of small businesses that do not have a working disaster recovery plan are destined to close within 2 years, after experiencing the disaster. Sadly, this is preventable, by regular testing and annually repeating of the DRP cycle.

The most effective testing method is what is called a Tabletop Exercise.

Tabletop Exercises start with a scenario, which leads to a sequence of possible events that may occur, leading to a disaster, often something minor like a data breach with a few twists. However, they can also lead to major disasters like a hurricane that has destroyed half the building. The tabletop exercise is often led by a single individual who only shares factual information. Members of the organization ask questions and if relevant or related the leader answers the questions with more information. The participating members then “play act” the implementation of the organization’s DRP based upon the event(s) as they unfold. This method tests multiple aspects:

1. Can the team (participating members) work together.
2. Can they see answers while under pressure (well preceived pressure)
3. Can they use the DRP according to the plan itself, do they know what actions or decisions need to be taken
4. Following the organization’s actual current plan, policies and procedures can the disaster be minimized or reduced
5. Afterwards the following questions can be assessed: Was the plan effective? Does it require modification? Was the plan executed to early or to late? Could things have been done better?

The outcomes of the questions can determine a lot about the plan and the organizations preparedness should a similar disaster arise. A much easier and cost effective solution, than waiting for a disaster to occur and then finiding out that the plan fails while in the middle of a real disaster.

Prepare = Plan = Test  ==> Be Ready

My 2c from small town America

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

In October 2008 OIG (Office of Inspector General) conducted an audit of CMS (Centers for Medicare & Medicaid Services) regarding their oversight of HIPAA.  Read the link for more information it is well worthwhile, though for many the impact may be subdued in auditees (auditor speak or lingo).

My summary of the [Click to Read more...]]]> Complaint Driven Vs. Audit Driven

In October 2008 OIG (Office of Inspector General) conducted an audit of CMS (Centers for Medicare & Medicaid Services) regarding their oversight of HIPAA.  Read the link for more information it is well worthwhile, though for many the impact may be subdued in auditees (auditor speak or lingo).

My summary of the report:

OIG was not very happy with the state of HIPAA oversight. They stated that the compliant driven process (which was the means of raising HIPAA issues from the start), is NOT an EFFECTIVE mechanism.

Their recommendation was that CMS investigate and re-address the compliance review process for covered entities, common auditor speak for implement an audit process of investigation.  The OIG even went as far as to point out that the current HIPAA regulation gives CMS and OCR (Office of Civil Rights) the authorization to conduct HIPAA Security Rule compliance reviews/audits of covered entities. Thus, they should have been doing this already.

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

So what does this mean for covered entities?  Well it means the kids gloves are off, and why do I say that.

COMPLAINT DRIVEN PROCESS:

Somebody had to be aware of what HIPAA required, see a violations (actual or perceived), then report the violation to CMS and/or OCR. Which would be reviewed and the possibly investigated.  The failure was part 1 “be aware of what HIPAA required”.  Having conducted numerous HIPAA awareness presentations to covered entities and I’m always amazed at the lack of understanding even 13 years later (2009 – 1996 = 13 years). My favorite questionnaire answer: Q: When was HIPAA written into law?  80% respond with A: 2003.  Oh what happened to the first 7 years of HIPAA?

AUDIT DRIVEN PROCESS:

Now CMS and/or OCR can call for a “semi-”scheduled review of a covered entity, much along the same lines as the “scary” Piedmont Audit. There are many links on the either do a Google searchthe one I liked the most was ‘ 42 questions.  It is amazing that still 2 years later there has been no official release of the Piedmont audit findings.

This is very alarming, as an auditor I question: Was the findings THAT BAD, that they could not be released?  Was the audit process not structured enough that it would be argued that it was not objective and/or comprehensive?  Why the secrecy? Surely HHS would want to prepare fellow covered entities with a documented and proven method of conducting a compliance audit, if for no other reason that they would be prepared.

SO HOW DO COVERED ENTITIES PREPARE?

One thing would be to start conducting their own in-house or internal driven audit investigations. Almost a what-if analysis should HHS schedule an audit this week where would the CE (covered entity) measure according to the regulation requirements.  Purely as a means to measure the difference between perceived compliance and actual compliance.  Just like many areas of business, awareness and preparedness are critical to success. Just think of BCP (Business Continuity Planning), we prepare and plan for the unforeseen negative events that *MAY* effect the organization. However, we still annually prepare for it.  (HINT: just in case you are unaware, yes HIPAA does call for annual BCP and DRP reviews ! ! ! )

A common mis-conception is that HIPAA is an IT / technical problem.  Not the case.   When you look at the Security Rule for HIPAA 3/6 : Administrative   , 1/6 : Technical  ,  2/6 : Physical. HIPAA is not an IT issue, however, IT can help make or break the compliance stance of the covered entity, yes.

So prepare for a HIPAA audit, don’t think you will pass, know that you will.

my 2c from small town America

(1) Attending the SANS webcast Virtual rountable: featuring Ed Skoudis, Mike Poor, and Hal Pomeranz, the discussion point concerning cyber warfare / cyber attack was raised due to the current activity against South Korean and US government networks.

(2) During the same week I was reading “The Management [Click to Read more...]]]> This was born out of two sequences of events:

(1) Attending the SANS webcast Virtual rountable: featuring Ed Skoudis, Mike Poor, and Hal Pomeranz, the discussion point concerning cyber warfare / cyber attack was raised due to the current activity against South Korean and US government networks.

(2) During the same week I was reading “The Management of Network Security” which the authors raised the concept, Properties of a Good Network Environment. The authors discuss the need for protection concerning the physical attributes of the network like, power, wiring, conduits, etc.. They refer to a few lessons learned from the hurricane Katrina and New Orleans disaster.

These two events got me thinking from an audit perspective how often we tend to down play (with very low risk probability) the risks around network connectivity reliability, IF we even have them on our risk assessment list in the first place. Remembering the Internet outage of Dec. 2008 “Mass Internet outages in Egypt” in which three Internet cables were accidentally cut off the coast of Sicily, causing a massive outage throughout Egypt.

I started to look around a little wondering about the frequency of “Internet outages caused accidentally by backhoes”. First I was surprised at the result 170 links (Isn’t our favorite search tool, Google, just great who can’t go a day without say thing thank you, but I digress.) In thinking about some discussions I have had with other IT auditors, we only tend to address Internet connectivity outages as a very rare thing, and thus do not much to pay much attention too it, also we often look at it with only one question “What if we were to lost Internet connectivity?”. I pose we should have an additional question: “OR what if, our main business supplier(s) lost connectivity and we can not access them?”

Looking through some of the links from the above Google search a few things become very apparent

• It is often completely accidental. My favorite quote was “An idiot with a backhoe, accidentally cut the line while digging.” Of course it could not have been done by a sane or non-idiot person.
• It often takes a few hours or more to find a quick/temporary solution and reroute the traffic. IF, that is even possible. It takes months to get a complete repair done and for things to go back to normal

• These are not small companies that have suffered these types of incidents (Verizon, Sprint, AT&T, to name a few) and they mostly are recent 2008 / 2009
• The backup solutions tend to be magnitudes slower than the mainstream connection.

• This is not only a US issue, but an International one, which leads me back to my point what if it is our business supplier lost connectivity. What with many companies using overseas call centers, overseas programming teams, overseas technology support hubs, etc…) Perhaps outsourcing IT resources is going to come back and haunt us someday?

So why then do we as IT security auditors down play the issue? Forward thinking IT administrators often secure redundant circuits from their Internet Service Provider. But, how often is the last leg into the building following the same non-redundant path? Or we secure two different means with two different bandwidth connection speeds, after all who is going to be able to justify paying for a second 10/20/30 M bps connection that is used, perhaps, well, never if all goes well? Should we as IT security auditors even worry about such issues and just declare them under AOG => Acts of God and uncontrollable?

My 2c from small town America

I guess the answer to the question depends on the lorg reader’s (the human reader) approach, feelings and job function/description. Sadly there are many “log readers” that seek the “instant society approach to completing their duties. They seek systems and applications to read the log files and [Click to Read more...]]]> System Logs: Nightmare OR Treasure trove?

Posted: October 03rd 2007

I guess the answer to the question depends on the lorg reader’s (the human reader) approach, feelings and job function/description. Sadly there are many “log readers” that seek the “instant society approach to completing their duties. They seek systems and applications to read the log files and give to them the “readers digest” or summary version.

Don’t get me wrong these systems: (1) are needed, (2) to a great job, and (3) have an important place and function. BUT they should NEVER be the “sole” method of analyzing log files. Unfortunately many “log readers” depend on the systems to read the log and tell them what is going on, instead of: (a) reading the log file themselves and using the human/neural logic to truly view what is happening, or (b) reading the output as an overview or starting point, and then digging depper to see ALL that is really going on in a specific area, entry or time frame. Another major factor as to whether or not log files are important is the placement or location of the device producing the log file within the overall network infrastructure.

For simplicity sake I’m going to change gears and look at just IDS log files the information in the article equally applies to ALL log files regardless of what system is generating the log file.

Most will say to place the IDS inside the firewall For example: you see this as a CISA practice test question. To place the IDS between the firewall and the Internal network. this will offer some protection as it will view and monitor all the traffic that the firewall has allowed through and will give you a very good, detailed account of what has entered the network (also what has passed out of the network). But this cannot answer: “What is happening with the firewall?” and “What is the firewall not allowing through?”. A key point sometimes we learn more from what we DO NOT know, as to what we do know.

There are many cases where knowing what the firewall is rejecting can be of more value and importance, to help us determine what attacks are taking place and therefore what actions need to be taken to prevent these attacks, even if it is just being aware that they are taking place. Perhaps we might want to know whether or not the firewall is performing everything that we want it to perform. We may have overlooked some form of traffic that the firewall is blocking and actually we want to allow it in! Then again perhaps some outside source is logging into the firewall and making their own changes, redirecting traffic out before it even comes in. As you can see some examples of not knowing what is being received by the firewall never mind what is being rejected. We are missing a lot of information just due to placement.

Then again placing the IDS outside the firewall will give is ALL the traffic that is rejected by the firewall, thereby logging much more traffic, that our network had nothing to deal with as it was rejected/blocked at the firewall and our internal network was none the wiser.

Additionally from an incident handling point of view it gives us two logs, the IDS and firewall logs, as proof of what traffic we had vital information from two sources for legal purposes. Obivously this leaves the IDS without the protection of the firewall. But there are ways this can be overcome.

The major draw back to placing the IDS outside the firewall is the vbolume of traffic it will record versus the volume of traffic it will record if placed inside the firewall. If the firewall blocks 70% of traffic received then the IDS (outside the firewall) will log 70% more information than the IDS inside. Thus coming bac to the point what does the information contained in a log file mean to the log reader? Is there an absolute right and wrong way, NO!!

The question is more what is to be viewed and what is to be learned/seen/known from the information inside the log file.

Perhaps a better alternative is two IDSs, once inside and one outside, thus coming back to the defense in depth principle, where there is multiple layers giving us different viewpoints of the traffic and thus perhaps more information to make better decisions. An even better approach would be an external IDS to detect everything coming to the firewall or boundary and an IPS inside the firewall to inspect and prevent anything that mistakenly got through the firewall. (IDSs just view or look at traffic. IPSs can react or respond to traffic as it processes it).

I guess the main point to make is do NOT ignore the value of log files. Those organizations that are audited know that auditors love to check whether or not the log files were reviewed and what was done with the information found in the log files. Many organizations that are not audited, they sadly ignore the log files and thus miss the very valuable information that they contain. Logs can be an enemy if you do not pay attention to them, or they can be your best friend if used and positioned correctly. But please DO NOT ignore your log files. More often that not you will be very surprised to see what the logs do record, that will make the security of the network much tigher. If for no other reason awareness of what is going on. Knowing what attack is taking place is half the battle to defeating the attacke from succedding and your network and above all else your data from being affected.

Of all the Compliance regulations, HIPAA stands out from the rest.

It’s been six years since the 2001 Enron scandal erupted, resulting in Compliance and Governance beguin elevated today.

Large (Fortune 1000 companies) have had to comply, and to a large degree, are quite willing due to the [Click to Read more...]]]> IT Governance, Why run from it?

Posted: August 29th 2007

It’s been six years since the 2001 Enron scandal erupted, resulting in Compliance and Governance beguin elevated today.

Large (Fortune 1000 companies) have had to comply, and to a large degree, are quite willing due to the benefits and streamlined process cycles governance creates. Mid Size organizations are in partial agreement, but do so with regret and resistance while, smaller organizations have done little or nothing to implement governance and are very resistive. This is not including the individual “mom and pop companies” that have not even been informed about governance or compliance.

How does this effect security Compliance? Governance and Security are closely related due the extensive and exessive use of technology within business processes today. Many companies have streamlined their production and have outsourced different process cycles to “business partner(s)”. This has been great from a business perspective, but terrible when you factor in security and compliance.

Large organizations have paid the price, and implemented strong governance and adherence to compliance regulations, while their business partner has done nothing to implement governance. A chain (security) is only as strong as it’s weakest link, and yet chains made from iron are being linked to chains made of paper.

We must consider does our business partner pay as much attention to security, compliance and governance as we do?
IF not, then what are we going to do about it! This issue must be addressed

Definitions:
Regulatory compliance refers to systems or departments at corporations and public agencies to ensure that personnel are aware of and take steps to comply with relevant laws and regulations. http://en.wikipedia.org/

Governance makes decisions that define expectations, grant power, or verify performance. It consists either of a separate process or of a specific part of management or leadership processes. Sometimes people set up a government to administer these processes and systems. http://en.wikipedia.org/

Incident Response plays a vital role along with an organization’s DRP (disaster receovery plan). We must be sure it is implemented correctly?

Incident Response has a preset structure: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned. These steps [Click to Read more...]]]> Why is Incident Respons So IMPORTANT?

Posted: August 28th 2007

Incident Response plays a vital role along with an organization’s DRP (disaster receovery plan). We must be sure it is implemented correctly?

Incident Response has a preset structure: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned.
These steps should be followed in sequence, yet very often we find ourseves in an adrenalin rush to “Fix IT, NOW!!!”, causing us to make mistakes in the procedure. For instance start with the containtment procedures before we have fully identified the incident. Is this right or wrong? One must actually identify the incident correct correctly, before you could properly tell.

Putting the above example aside, the next biggest mistake made in incident response is second guessing. IF containment is started before identification is completed, continue on and address it during lessons learned. NEVER second guess and say “Oh we shouldn’t have done that, let me undo that/those step(s).” It’s too late, what is done is done. HOWEVER, remember that your actions are always influenced by prior decisions, thus the purpose for the pre-defined steps.

The ONLY real incorrect approach to incident response however, is ignoring it all together, or not seeing that an event was in fact an incident.

Be safe.

Posted: August 27th 2007

In talking with multiple busines partners, it never ceases to amaze me that there is such a small grasp of [Click to Read more...]]]> Does SAS 70 imply tight security?
Does SAS 70 prove no vulnerabilities?
These questions and more are answered for your understanding.]]>

Why is SAS 70 confused with security?

Posted: August 27th 2007

In talking with multiple busines partners, it never ceases to amaze me that there is such a small grasp of what IT security truly is.

Take for example a discussion I had just the other day. I was told “Our security is fine, afterall we passed our SAS 70 audit”. A SAS 70 audit does not prove that security is good or bad. A SAS 70 is strictly an audit on controls and control effectiveness, not security. For Example: IF a company has a policy that states all employees must be at work by 8:00am. Then SAS 70 will audit to see that this is in fact being adhered to. If there was no policy in place, then there would be no control objective, thus the current control process would be acceptable. In other words no policy or a working adhered to policy are good SAS 70 reports, while a non working policy is considered a bad SAS 70 report. None of these circumstances however are checking for the security of employees, just their arrival times and effectiveness.

We don’t expect the isle in the grocery store to sell cooking oil with motor oil!! Why then do we expect our finanical accountants and auditors to understand the technical details of IT security? Let the accountants focused on financial data and let Technical IT professionals focus on our security.

Please do not waste your company’s time or money on the misconception that it is secure. Please get a proper security audit from an IT security professional.