Computer Security Incident Response

Computer incidents happen.  They just do.  Regardless of the expansive and proactive nature of a particular team, the Computer Network Defense (CND) job will include Incident Response.

Why?  Because in part, CND is reactive.  A properly running CND team will include a subgroup of Attack and Exploitation members who will actively look for vulnerabilities in your network, but that subgroup is dwarfed by the number of active attackers in the world.

So what should a CND team do?  The team should prepare for incident handling and response.  As it turns out, when it comes to incident handling and response, prior planning provides utmost performance.

A brief history

In the beginning was ARPA. And the Internet was with ARPA.  And the Internet was ARPA.  The Advanced Research Projects Agency (ARPA, later known as DARPA) network was the precursor of what we now know as the Internet.

In 1988, Robert Morris made international history… by mistake.  A young Cornell student at the time, Morris crafted what became known as the Morris Worm.  The worm was intended to gauge the size of the then current internet through a sequence of weak passwords and services available on most networked devices at the time.  But Morris poorly coded his worm.  The mistake was that the worm would reinfect the host computer as well as spread to other computers, thereby overwhelming the host computer with processes.  When a network engineer or systems administrator rebooted the machine to regain access, the nearby computers would quickly reinfect the machine.  Recovery was not a simple task, and the Internet came to a halt.

At the time, DARPA and the Defense Department were positioning the have a guaranteed delivery, always available information network.  The Morris Worm helped them realize the vulnerability of the net, and their response was to create the Computer Emergency Response Team (now known as CERT[tm]) hosted under the Software Engineering Institute (SEI) at Carnegie Mellon University.  The charter for CERT was created to be a coordination center for computer network operations defenders in the US and around the world.

The NIST Incident Guide

NIST’s Computer Security Incident Handling Guide is an excellent source of how to organize and design a Computer Security Incident Response Capability.  Realize, it will take some time to digest the entire document.  You’ll have to forget some ideas you’ve likely held on to, and learn new techniques that have been proven in the art of incident response.

But why would you want to rewicker your incident handling policies, and plans, and procedures?  This is a costly endeavor, no?  Well, yes, it is.  But it is going to help your organization prepare for incident response, will help in the process of incident response and recovery, and may even help in preventing an incident in the first place.

If your management is resistant to reviewing the policies, plans, and procedures in place, you might want to help them reconsider their position.  If you happen to work in an industry or at a company who is responsible to external validation, or maintaining information that requires response to incidents (read this: just about everyone, including those who handle SOX, PHI, PII, PCI, and nearly any other data), you might want to make sure your policies, plans, and procedures follow NIST, even if not strictly required.  When you are breached (and it is a when, not an if), your adherence to NIST or other standard is likely to go a very long way in reducing your fines.

Reviewing the NIST guide

The NIST Computer Security Incident Handling Guide is very well thought out and presented.  The following sections take abstracted direct quotes from the NIST guide.

Chapter 1: Introduction

This document has been created for computer security incident response teams (CSIRTs), system and network administrators, security staff, technical support staff, chief information security officers (CISOs), chief information officers (CIOs), computer security program managers, and others who are responsible for preparing for, or responding to, security incidents.

Chapter 2: Organizing a Computer Security Incident Response Capability

Organizing an effective computer security incident response capability (CSIRC) involves several major decisions and actions. One of the first considerations should be to create an organization-specific definition of the term “incident” so that the scope of the term is clear. The organization should decide what services the incident response team should provide, consider which team structures and models can provide those services, and select and implement one or more incident response teams. Incident response plan, policy, and procedure creation is an important part of establishing a team, so that incident response is performed effectively, efficiently, and consistently, and so that the team is empowered to do what needs to be done. The plan, policies, and procedures should reflect the team’s interactions with other teams within the organization as well as with outside parties, such as law enforcement, the media, and other incident response organizations. This section provides not only guidelines that should be helpful to organizations that are establishing incident response capabilities, but also advice on maintaining and enhancing existing capabilities.

Chapter 3: Handling an Incident

The incident response process has several phases. The initial phase involves establishing and training an incident response team, and acquiring the necessary tools and resources. During preparation, the organization also attempts to limit the number of incidents that will occur by selecting and implementing a set of controls based on the results of risk assessments. However, residual risk will inevitably persist after controls are implemented. Detection of security breaches is thus necessary to alert the organization whenever incidents occur. In keeping with the severity of the incident, the organization can mitigate the impact of the incident by containing it and ultimately recovering from it. During this phase, activity often cycles back to detection and analysis—for example, to see if additional hosts are infected by malware while eradicating a malware incident. After the incident is adequately handled, the organization issues a report that details the cause and cost of the incident and the steps the organization should take to prevent future incidents. This section describes the major phases of the incident response process—preparation, detection and analysis, containment, eradication and recovery, and post-incident activity—in detail. Figure 3-1 illustrates the incident response life cycle.

Chapter 4: Coordination and Information Sharing

The nature of contemporary threats and attacks makes it more important than ever for organizations to work together during incident response. Organizations should ensure that they effectively coordinate portions of their incident response activities with appropriate partners. The most important aspect of incident response coordination is information sharing, where different organizations share threat, attack, and vulnerability information with each other so that each organization’s knowledge benefits the other. Incident information sharing is frequently mutually beneficial because the same threats and attacks often affect multiple organizations simultaneously.

As mentioned in Section 2, coordinating and sharing information with partner organizations can strengthen the organization’s ability to effectively respond to IT incidents. For example, if an organization identifies some behavior on its network that seems suspicious and sends information about the event to a set of trusted partners, someone else in that network may have already seen similar behavior and be able to respond with additional details about the suspicious activity, including signatures, other indicators to look for, or suggested remediation actions. Collaboration with the trusted partner can enable an organization to respond to the incident more quickly and efficiently than an organization operating in isolation.

This increase in efficiency for standard incident response techniques is not the only incentive for crossorganization coordination and information sharing. Another incentive for information sharing is the ability to respond to incidents using techniques that may not be available to a single organization, especially if that organization is small to medium size. For example, a small organization that identifies a particularly complex instance of malware on its network may not have the in-house resources to fully analyze the malware and determine its effect on the system. In this case, the organization may be able to leverage a trusted information sharing network to effectively outsource the analysis of this malware to third party resources that have the adequate technical capabilities to perform the malware analysis.

This section of the document highlights coordination and information sharing. Section 4.1 presents an overview of incident response coordination and focuses on the need for cross-organization coordination to supplement organization incident response processes. Section 4.2 discusses techniques for information sharing across organizations, and Section 4.3 examines how to restrict what information is shared or not shared with other organizations.

Appendix A: Incident Handling Scenarios

Incident handling scenarios provide an inexpensive and effective way to build incident response skills and identify potential issues with incident response processes. The incident response team or team members are presented with a scenario and a list of related questions. The team then discusses each question and determines the most likely answer. The goal is to determine what the team would really do and to compare that with policies, procedures, and generally recommended practices to identify discrepancies or deficiencies. For example, the answer to one question may indicate that the response would be delayed because the team lacks a piece of software or because another team does not provide off-hours support.

The questions listed below are applicable to almost any scenario. Each question is followed by a reference to the related section(s) of the document. After the questions are scenarios, each of which is followed by additional incident-specific questions. Organizations are strongly encouraged to adapt these questions and scenarios for use in their own incident response exercises.

Appendix B: Incident-Related Data Elements

Organizations should identify a standard set of incident-related data elements to be collected for each incident. This effort will not only facilitate more effective and consistent incident handling, but also assist the organization in meeting applicable incident reporting requirements. The organization should designate a set of basic elements (e.g., incident reporter’s name, phone number, and location) to be collected when the incident is reported and an additional set of elements to be collected by the incident handlers during their response. The two sets of elements would be the basis for the incident reporting database, previously discussed in Section 3.2.5. The lists below provide suggestions of what information to collect for incidents and are not intended to be comprehensive. Each organization should create its own list of elements based on several factors, including its incident response team model and structure and its definition of the term “incident.”



  2. History of the Internet,
  3. Morris Worm,
  4. CERT is a Registered Trademark of CMU,
  5. CERT/CC,
  6. CMU,
  8. Computer Worm,
  9. SEI,


Zero day, 0day, ohday, oh my!

APT2014 was yet another banner year in Computer Security.  The industry met with the Heartbleed SSL vulnerability, Point of Sale equipment attacks against Target and Home Depot, and the Shellshock vulnerability in a piece of software that has been around for more than twenty years.

If you happen to not remember any of those, well, you must be happily sailing the islands.  Good for you!

But for the rest of us in technology, and particularly for those in computer security, we’ve had quite a year.

One of the outgrowths of these vulnerabilities being exploited has been that it seems “everyone” has heard the term “zero day”.  But what is a zero day?

Before we begin

Before exploring anything else here, let’s set the record.  Regardless of a formal definition of zero day, the responsibility of the defense team is to prevent loss of confidentiality, loss of availability, and loss of integrity of data and systems.  The responsibility (if you will) of the attack team is to do just the opposite.  In some ways, defining zero day is going to feel like a lesson in academics.  In some ways, it is academic.  That said, let’s move on.

Exploits vs Vulnerabilities

As we define 0day, let’s explore a couple of supporting ideas.  Let’s start with Exploits and Vulnerabilities.

In security, a vulnerability is a weakness that allows a threat to compromise the integrity of a resource.  NIST SP 800-30, “Risk Management Guide for Information Technology Systems”, defines vulnerability as  flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system’s security policy.

That said, an exploit is an attack on a resource that takes advantage of a vulnerability.  Think of it this way.  A vulnerability is an attack surface.  But it takes a special kind of vulnerability to be exploitable.  There is no exploit unless a vulnerability exists, but not all vulnerabilities are exploitable.

Let’s create a non electronic based example to help understand the ideas.  Let’s say you keep paper copies of all credit card transactions in a file cabinet.  You are vulnerable to having all of this PCI data compromised and stolen by an adversary.  The vulnerability is that all PCI data is in a file cabinet, so the exploit would be that someone walks in and takes your file cabinet.  What do you do to control the vulnerabilities?  You’ve placed locks on the cabinet and your front door, and you’ve hired an armed security guard and guard dog to police your premises.  Because of these safeguards, the original vulnerability is moot.  The new vulnerability is several steps deep, a defense in depth.  Now the adversary has to disable the dog, disarm the guard, pick the lock on the front door, and pick the lock on the cabinet.  You still have vulnerabilities, but the combined effort of all those vulnerabilities must be exploitable at the same time in order for an exploit to occur.

The elusive Zero Day

Computer Key with binary et alNow that we understand Vulnerability chains and Exploitability, let’s come to an understanding of what a zero day is, and what a zero day is not.  If you’ve seen literature about a security vulnerability, that vulnerability is likely not a zero day (I’ll get to that “likely” word in a moment).  To be comprehensive in this discussion, the systems may remain vulnerable to attack after a vulnerability is patched, but the vulnerability is not a result of the zero day, the vulnerability is a result of an unpatched system.

“Wait, what?”,  you might be asking.  “How is a zero day any different than an unpatched system vulnerability?”  Okay, let’s try this.  A zero day is a vulnerability in which the protectors have had no days to create a patch for the system.  If the protectors are aware of the vulnerability, then it is no longer a zero day.

That said, a vulnerability that has been presented to the protectors but in which a patch has not been created or has not been deployed still results in a vulnerability, but those vulnerabilities are no longer zero day.  But really, zero day is even a little more elusive than this.  Let’s be honest.  Being hit by an exploit will always feel like a zero day, because you likely did not take the attack vector seriously.

Timeline of vulnerabilities

Protecting systems often relies on patches.  So what is a reasonable timeframe between presenting a vulnerability to the vendor and a patch?  Some reports identify that it takes vendors more than ten months to develop a patch.  Google has put the brakes on this long forecasting though.  Google’s Project Zero gives the vendor 90 days between the time of vulnerability presentation to the vendor and the time the vulnerability is made known to the world.

Exploiting the SDLC

Opportunity Ahead Road SignExploiting systems truly relies on exploiting the Systems Development Lifecycle (or SDLC).  The SDLC starts with the first thoughts of a system, and continues through retirement or disposal of the system.  Wikipedia has a great article on SDLC, and we’ll visit and organize a few steps that are particularly important when discussing exploitation:

  1. (development) The development team creates software
  2. (initial deployment) The software is distributed to end user teams
  3. (installation) The software is installed by end user teams
  4. (feedback) The development team is made aware of requested upgrades and security issues.
  5. (patch development) The development team creates patches
  6. (patch deployment) Patches are distributed to end users
  7. (patch installation) End user teams install the patches
  8. (repeat) Repeat to Feedback loop
  9. (end of life) At some point the product will reach End of Life and no longer be maintained.

Ripe times for vulnerability discovery exist at the following points, and the vulnerability discovery teams will hand off those vulnerabilities to exploit developers:

  1. Between Initial Deployment and Installation.  Hackers will get the software and try to do daring things to it, sometimes even before the first end user team has installed it.  Any vulnerabilities discovered here are clearly zero day vulnerabilities.
  2. Between Feedback and Patch Development.  Hackers will look at public blogs and websites where bug track issues and core dumps are reported, to determine if any of the logs identify vulnerabilities.  Bugs that translate into vulnerabilities are not really zero days.  Instead, these vulnerabilities are known vulnerabilities that are not yet addressed.  But this definition could be a matter of semantics, and to argue the issue is not worthwhile.  From the point of view of an attacker, they are vulnerabilities.  From the point of view of the victim, they are vulnerabilities.
  3. Between Patch Deployment and Patch Installation.  Hackers will look at patch deployments — especially security patches — to determine what vulnerability existed in the prior version.  This point in time is one of the most prolific in the days of a vulnerability researcher.   These are not zero days.  These are known vulnerabilities, and the systems remain vulnerable only because the end user hasn’t been responsible and deployed the patches.  The attack surface is a result of unpatched systems, solely the responsibility of the end user.
    For an example, Microsoft’s Patch Tuesday invariably results in Exploit Wednesday.  Why?  Because it takes awhile for all users to update their systems.   Oftentimes business users will refrain from patching immediately because of incompatibility with other products.
  4. At and after End of Life.  Hackers will take advantage of end of life product in that zero days last forever once the development team has left the update cycle.  These vulnerabilities are sometimes referred to as zero days forever.
    Case in point, when Microsoft announced the end of updates for Windows XP, they also described how attackers will lay waste to users who remain on XP.

Zero day… What it means to me

So here’s the short of it all, and let’s revisit our previous definition.  A pure zero day is that moment in time between when an attacker knows about the vulnerability and the defense team knows about the vulnerability.  The exploit team is using it, and the defense team doesn’t know about it.

Computer Network Attack

hacker green backTo better defend your network, it is a good idea to understand how the adversary is going to attack your network.  From the perspective of the Computer Network Attack & Exploitation (CNA/CNE) teams, the job is to find vulnerabilities and build exploit paths.  How is this done?  CNA teams will:

  • Become aware of anomalies through publicly available crash dumps, bug reports, and forums where users of any particular piece of software discuss issues.  If  a system crashes or produces otherwise unexpected results, there is something wrong — and that something may turn out to be a real vulnerability, and in turn that vulnerability may turn out to be exploitable.
  • Reverse engineer patch code and compare it to the unpatched versions, especially anything identified by the vendor as “security patch”.  Realize if you find a vulnerability, you are in a race to attack the unpatched systems in the wild before the end user patches those systems.
  • Do what you can to create anomalies.  Look at the touch points on the system, be that a network, a keyboard, or some other input device.  Use tools such as Metasploit and fuzzers to force the system to do things it wasn’t originally designed to do.
  • Be realistic.  For every million well crafted test cases, be happy with a thousand anomalies.  With a thousand anomalies, be happy with a couple of repeatable vulnerabilities.

Computer Network Defense

If you are on the Computer Network Defense (CND) team, your job is to protect the network from known and unknown (0day) attack.  How?  Keep abreast of the product user community blogs to see what other people are reporting, and keep in touch with your own users to determine if they witness anomalies on the platform.  What should you do?

  • Expect an anomaly is a vulnerability.  There may not be an exploit path, but an anomaly is where every vulnerability is birthed.
  • Do what you can to isolate systems in general, and certainly any oddly acting systems.  Network isolation is a great place to start.
  • Patch early, and patch often.  Realize that when a patch becomes available, the CNA & CNE teams are reversing those patches to discover vulnerabilities and explore exploitation paths.
  • Be prepared with a patch plan.  If a patch breaks one of your existing applications, be prepared to isolate the system instead of leaving an unpatched system in your universe.
  • For particularly difficult deployments where existing applications are known to not work with the most updated patches, use Virtual Machines to isolate those applications.

Conclusive notes

Remember, all of this is a race against time.  Eventually (and yes, it may be years), every vulnerability will become publicly available and known, and once known the vulnerability will likely be eradicated through a patch or the exploit path will be nullified through isolation.

And as always, regardless of what side of the fence you are on, let’s be careful out there.

Reference documents

  1. NIST SP 800-30, “Risk Management Guide for Information Technology Systems”
  2. Heartbleed SSL vulnerability,
  3. US-CERT Alert on Point of Sale exploitation,
  4. Shellshock vulnerability,
  5. Google’s Project Zero,
  6. Microsoft Patch Tuesday,
  7. Defines Zero Day Vulnerability, “A zero day vulnerability refers to a hole in software that is unknown to the vendor”,
  8. Zero Day, “A zero day exploit is when the exploit for the vulnerability is created before, or on the same day as the vulnerability is learned about by the vendor”,
  9. Zero Day Vulnerability, “A zero-day vulnerability is previously unknown vulnerability in a software”,

Search Engine Optimization

Search Engine Optimization, or SEO, is a common phrase for “How do I get my web site highly ranked on Google!?” I’m simplifying this of course, but it is good enough for our use.

But really, let’s think about this a bit.  Do you care about SEO, and being highly ranked on Google?  Well, sure you do!  But … not really. Let’s be honest.  What you really care about is business.  Traffic, and driving traffic to your site, and converting that traffic into… business.  So what you really care about is business, and increasing that business.  I’m with you, and this “getting started in SEO” article is going to help you along.

To SEO, or not to SEO.  Is that even a question?

To start this exercise, let’s consider our goal again.  Our goal is to increase business, and we are going to do that by increasing traffic.  There are a few kinds of traffic:

  • There are new visitors who happen along our page because we’ve distributed business cards, or put up billboards, or paper advertising, or a customer or visitor has referred them to us, or we’ve had other personal contact with them.  These are direct contact visitors.  Any Page 1 ranking doesn’t matter for these visitors — but SEO is still very important.  Why?  Because we want to retain those customers, and have them visit again.
  • There are new visitors who happen along our page because they are referred to us by other web sites.  These are referred visitors.
  • There are new visitors who happen along our page because they searched for a certain term.  These are SEO visitors.  This traffic is directly influenced by our SEO work that helps our ranking.  We want to grab that person’s attention, and have them visit again.
  • There are visitors who happen along our page because they’ve already visited.  These are repeat visitors.  We definitely want to capitalize on repeat visitors and have them return to our site!  Why?  Because it is very costly to get that first time customer.  Customer retention is important in any business.

In the following chapters, we’ll visit each of these types of visitors, and try to better understand how to keep them around.


Let’s start with the now infamous backlink.  Don’t worry, it is okay if you haven’t heard of them before.  There was a day when ranking was almost purely based on keywords and the number of backlinks to your site.  The more the backlinks, the higher the ranking.  The idea was, a spider would reason if so many people feel confident about this particular web site, then well, maybe I should feel confident about this particular web site too.

But then backlink farms started growing.  These were web sites almost purely devoted to backlinks.  No real content, just hey, pay me a dollar and I’ll let you have your very own backlink to your site to help in your ranking.  What was the response?  Right.  The search engines realized the failure, and the algorithm changed a bit.  A site would be ranked based on a rough estimate of backlinks to outlinks.

I got caught on outlinks with my first web site.  I achieved front page status on all the popular search engines of the time (yay!), then I decided to outlink for key words to dictionary sites (to help my reader with unusual words and technical jargon), and outlink to companies I did business with (to help my reader more easily find companies in the “digital era” of web sites), and outlink to the weather reports (because I am a boater and pilot, and weather is important to both of those interests), and to financial times news (since at the time I was actively involved with heavy day trading, it just seemed to make sense to link to these sites).  Well, what happened was… my first page results went to page 167 on google alone (no lie, I checked!).  At first I didn’t understand what happened.  It was a week or two between the time I started adding the outlinks, and the time I noticed that the site was no longer on page one.

I was able to get back to page one, but it was a slow process.  Just like the stocks I owned, they went down quickly, and took a long time to recover.  Eventually I was back to page one — unlike my stocks that mostly never recovered, but that is another story…

Anyway, today backlinks are “likely” part of the puzzle for these highly secretive proprietary search engine algorithms, but there is more.  Let’s get to a few others.

Be awesome in your field!

So let’s consider this a bit.  The first thing you need to do is define your business.  What are you doing?  Are you running a dry cleaners?  Then be awesome at it!  Are you opening a restaurant?  Then be awesome at it!  Are you creating a web services company?  Then… right, be awesome at it!  Why?  Well, here’s why.

If you open a restaurant, what do you provide to your customers?  Right, you provide food.  But you do more than that.  How do you keep customers coming back?  It usually isn’t only food, and not even only good food.  Think about it, why did Seinfeld revisit The Soup Man?  It is the atmosphere, the attitude of the wait staff, the cleanliness of the restaurant, the cleanliness of the restrooms, and even more.  If it were just food, most people would be just as satisfied to eat out of a can from the local grocery store.  But by providing good food, and good service, you are building a solution.  Even McDonald’s and Burger King do more than provide food.


Just as in the “develop your own web site” document, let me reiterate that content is king.  If you have good content, a few good things happen.  First, the search engines themselves recognize that it is really content and increase your rank.  Second, people will actually look at your site and look over the content — I mean, what good is it if you have achieved the legendary Page 1, but you don’t have any decent content?  Right, you get hits with no retention.  Not good.  And third, people will begin to backlink to your site without your even needing to ask!

Consider also, the better the content, the more rich, fully vetted content you can provide, the more easily the search engine is going to be able to realize what your site is about.  Not only that, the better, more rich, fully vetted content you can provide, the more easily a human reader is going to enjoy your site, and the more likely the human reader is going to return.

Fresh content

Okay, so you are awesome in your field.  People love your < pizza | law office | physical therapy practice | weblog | insert widget here >. You have great content on your site, you’ve written all about your cookie recipe, and how it won an award in 1999, and how you won the gymnastic gold medal in 1986.  How do you keep the visitors coming back?

The answer is:  Fresh content!

If someone visits your pizza palace and enjoyed the experience, they might be inclined to return — but you ought to be providing fresh pizza ingredients!  In the same way, if someone has visited your page once and enjoyed the experience, they may be inclined to return — but you ought to be providing fresh content!

But what is fresh content?  It depends.  If you are, you provide fresh content in several categories — International events, weather, local events, sports, the stock market.  These are reasons customers revisit  If the content is stale, then fewer people are likely to return.  You get that first costly hit, and then… nothing.  There is no reason to return tot he site.

Are you involved with homelessness and child welfare?  Well, how about fresh newsworthy content on developments in the world and the community that directly affect homelessness and child welfare?  That might entice people to return.

Are you the pizza palace?  How about fresh content like coupons, or discounts for the day, or “special events” where you give away a free pie, or free wine tasting with a the purchase of meat lovers pizza?  Right, there are ways to encourage people to revisit your site.  But mostly, you are trying to convert those site visits into business, and business is buying that pie!

If you are a web services company, you also need to build content, just like food is content.  But more than that.  You need to build good content, and fresh content to keep your customers interested in coming back.  That first click is hard to achieve — just like getting that first customer through your door at a restaurant is hard to achieve.  After spending thousands of dollars on advertising, you reasonably have one chance to convince that customer to return.  Having good fresh content is a great way encourage that return visit.


Keywords will definitely help your search engine ranking.  Consider, how would a search engine know you are a lawyer without actually using associated key words and phrases like law, attorney, law firm, criminal, defense, injury law, or contract law?  But consider also, every other lawyer out there is going to be interested in using those same key words.  Well what about key word stuffing?  Like, if I can repeat “attorney” on my site more than the next guy, will that help me?  Likely not.  In fact, it likely will hurt.  Key word stuffing is like ballot box stuffing.  It has been caught, and most search engines are going to penalize the site for stuffing that key word box.

What do we do then?

As we’ve seen, SEO is more than just getting on Page 1.  It is about providing such a great service that your existing customers are talking.  It is about providing such great content that people want to return.  It is about building a solution that people want, and the Page 1 rank is almost secondary.

Okay, well, all that except for the last part.  Page 1 is SEO.  But all that other stuff is critical to convert a traveler through your page to a traveler who builds your business.

So then, how can you stand out?  With key words alone, it is going to be tough.  With backlinks along, it is going to be tough.  With static web page content alone, it is going to be tough.  You need a splattering of key words through your fresh, awesome content that people want to read!

What do we do?  We write articles that will entice the reader to return to your page, and that will entice him or her to say, “Hey, I found this great law site, and the content is awesome!  You need to check it out.”

That is what we do.


Business Continuity and Resiliency Planning

what business continity plan
Business Continuity Planning? Yes, even you need it!

Are you responsible for business success?  Have you thought about what to do on those imperfect days?

The electricity goes out, your computer starts smoking, or one of your employees has an accident on the way to a very important delivery.

All of these are part of Business Continuity Planning (or BCP). The phrase BCP really took off after 9/11, along with Disaster Recovery Planning, but it has always been a part of a business plan, even if it is not written down.

In Business Continuity and Resiliency Planning, we attempt to put some order to the chaos. The paper is not a basic BCP tutorial, but instead is written just to get you to think about your business, what might happen to cause an interruption, and what you can do to lessen the opportunity for a disruption and lessen the impact of a disruption.

Happy reading! By the way, I’d love to hear your feedback!



Abstract for

Business Continuity, Resiliency, and Disaster Recovery Planing

Yay, you are in business! You’ve created your company, you have your occupational license, your office and storefront set up, vendors, product lines, and best of all, customers!

But are you ready to open? What happens when things go wrong? Let’s face it, adversity comes in many flavors. Sure, emergencies like a fire, and disasters like a hurricane are adverse, but there are more adversities to consider. A storm, or a crime, your internet goes down, or even something like if your suppliers stop supplying.

So what happens during these adverse conditions? What are your real risks, and how will you protect your business – and your customers – from the risks? Good resiliency planning will keep your business operating when things just don’t go right.

This paper helps you explore your exposure to risks and remedies for adversity. You don’t want to be in a position of trying to figure out what to do during a crisis. As some of us have heard through the years, prior planning prevents poor performance. Will this planning make you 100% safe from adverse conditions? Of course not. What it will do, though, is help you understand the risks your company faces, and help you get through the situations.

In this paper, we’ll focus on business continuity and resiliency planning as it relates to your product, to your business process, and to retaining your customers. We’ll look at snippets of what winds up being important to different kinds of businesses, including an Ice Cream Shop, a Home Health Agency, a roofing company, and a Restaurant. Although the content is appropriate for all businesses, the intended audience is the small business. We’ll avoid going through the purely educational process of defining Business Continuity and Disaster Recovery; instead, we’ll look at practical, real life examples of what you need to consider when it comes to protecting the interest of your company.


Chapter 1 Introduction to Business Continuity

When it comes to starting your business, there is no one “right type” of plan. There are business development plans, financial and budget plans, marketing plans, and recycling plans to name just a few. These are all great plans, and very important to any business. But let’s face it, some are more important than others.

And when it comes to protecting your business from adversity, there is truly no one “right type” of plan. These are the plans that you hope to never use, plans that are only important when things just go wrong. But equally so, these plans are important – to both your customers, and to your business interest. Take these examples,

  • What happens if your building burns to the ground? Are you going to set up shop at a temporary facility, or will you cancel all pending orders? How long will it take to recover? And how many pending orders will you lose? How will this affect your customers? To manage this risk, have you installed sprinkler systems? Or a fire alarm that automatically calls the fire department when things go wrong?
  • How about a hurricane warning? Do you send your workers home? How is your customer base affected by hurricane warnings? If you are selling water, you stay in business since everyone and their brother will be looking to buy water! But how about if you are an Ice Cream shop? Do you expect to get much business while everyone is scurrying around trying to board up their windows? How about if you are a licensed Home Health Agency? You may have government regulatory demands in place that force you to stay open, or maybe even force you to move all of your patients to a safe house for continued care.
  • How about a tsunami that happens quite quickly? You may say, “Oh, but I’m in Florida, we don’t have tsunamis.” This is true, you don’t. However, your suppliers may by affected, and if your suppliers are affected, you are affected. Take for example the 2011 earthquake and tsunami that affected Japanese LCD and semiconductor manufacturers, thereby disrupting the worldwide supply of these components.

Certainly, you may not know at this moment what you will do in these situations. It will likely depend on many factors, such as what is your business backlog of orders. However, it is never a bad idea to have a plan, and planning may even clear up some of these unknowns.

As a reminder, plans are just that, just plans. As Winston Churchill is quoted, “Plans are of little importance, but planning is essential.” Yeah, maybe. Then Mike Tyson tells us, “Everyone has a plan until they get punched in the face.” What do we take away from all this? Have a plan, but don’t be a slave to it. Be comfortable in changing the plans as necessary. These types of plans are truly living documents. You already know your business. As you get to know more about risks, your risks plans will become more mature. In these first phases, you may or may not even document the plan – the goal is to understand your risks.

Let’s look at what we are trying to achieve here and set some expectations. This is not a Business Continuity Training document. It is intended to look at real life threats and impacts to your small business. When we think Business Continuity, we should be thinking about, “what are the threats and risks to my business when it comes to completing my mission.” That is, what adverse situations might happen that will negatively impact completing your business goals. In this document, we’ll be looking at ways to reduce the impact of those adverse situations. We will be examining real life scenarios for real life companies, including a retail ice cream shop, a home health agency, and a restaurant.

This paper will consist of the following sections. First, we will lay out objectives or principles of the risk plan that we are writing. Next, we will brainstorm business continuity threats and risk impacts to your business, taking note of all conceivable risks (some of these will be unreasonable, and we can eventually discard them as unreasonable). Then, we will outline how to document the business continuity risks and associated mitigation. Finally, we will detail some of the risks and mitigation steps required to successfully keep your business running. Along with this, we will outline how much it is going to cost to implement the risk mitigation. We’ll end with some concluding remarks and way forward for developing a more comprehensive business continuity plan.

<< Continue reading Business Continuity and Resiliency Planning >>

Information Warefare and the software developer

cyber warfare attacker
Is a hacker lurking? You bet!

So you fancy yourself a software developer. Great! Me too.

But what is your take on hackers and the craft of cyber warfare? Do you think you write hack safe code? Fact is, people are out there that want to

  • get on your systems,
  • get on your customer’s systems,
  • get your data, or
  • otherwise compromise the integrity of your technology.

That’s all fine and dandy, but surely this can’t happen to my code, right? Well, wrong.

If you are writing router software or Operating System software, you know the importance of creating safe, secure code. But how about a game programmer? Is it really necessary to put the extra effort in to make your code safe? You bet it is.

Maybe your code is just the way the hacker gets on the system, looking for more gold at the end of the tunnel. We’ll talk more about this and examine even more questions you may have about hackers and protecting your code and your customers in this paper. Remember, the best security is built into the system, not bolted onto the system.

Information Warfare and Your Responsibilities as a Software Developer – Introduction to understanding hackers and protecting your software against attack was created to promote awareness and motivate the software developer into further research. It is not exhaustive, and does not cover all potential vulnerabilities. It is only an overview of hacking, and a few common vulnerabilities that can be easily addressed by the software developer. Be sure to open the Speaker Notes for more information on each slide.

Happy reading! And remember, let’s be safe out there… you are part of the cyberwar.

Goodbye Landline Phone – get rid of the local exchange

So you’ve looked at your local phone bill and it was… oh my, I’m paying that much for a simple phone number? This doesn’t seem right! How can I be paying $40 a month for a land line phone?

Well it doesn’t matter how you wound up paying that much. The unfortunate answer is that you are. That monthly fee turns out to be $500 per year after taxes. Yikes! But are there any real, viable, and safe options? And further, are you really ready for a change? I mean, it is only $500 a year. Most of us pay more than that eating fast food every year.

If your answer is, “Yes! I am ready for a change! I’m ready to ditch my landline! I’m ready for an alternative that will save me some dough!”, then you are in luck! This paper is for you. We’ll talk about the pros and cons of different services, and even the “risks” that you will face with getting rid of your phone line.

Ditch the landline is focused on the home user or small SOHO user. It is not a technical step-by-step or “how to” document (of which many exist), it is a document to get you comfortable and thinking about the switch. Sometimes you just need to know your options before you make a decision; if that is you, this paper is for you.

Please contact me for more advanced opportunities like private branch exchanges and other multiple user deployments.

<Originally posted 2011 on phoneexchange>

Using Artificial Intelligence to create predictive systems

Are you interested in Artificial Intelligence?

AI was coined in the mid 1950s, and was heavily funded by the Department of Defense for many years. Unfortunately, the practitioners at the time were overly optimistic and failed to identify some of the difficulties that they eventually faced. By the mid 1970s, funding was largely cut in favor of more promising projects.

In the early 1980s, AI resurged with the commerical success of a branch called Expert Systems. But again, there were issues, and AI fell back into hibernation and had followings mostly in research institutes.

By the 1990s, AI came back again, especially focused on analyzing information and data mining. In 1997, Deep Blue became the first chess computer to beat the world champion Garry Kasparov. In the 2000s, the Defense Advanced Research Projects Agency developed successful autonomous vehicle programs known as the DARPA Grand Challenge and Urban Challenge that could navigate both desert trails (a rugged 131 mile track was used in the demonstration) and urban environments (a 55 mile track demonstrated), all the while obeying traffic laws, hazards, other vehicles, and even pedestrians. We see these technologies in our cars today.

Applying Neural Networks to Investigate Electrical Power Plant Cooling-Water Discharge Temperature describes using AI for data mining and forecasting. The focus is on using AI (in this case, a branch known as Neural Networks) to create predictive algorithms dealing with the cooling water in electric power production. My interest in part was in line with the Environmental Protection Agency’s desire to protect the manatees who make a home in Tampa Bay.

Happy reading! By the way, I’d love to hear your feedback if you do decide to read.




This thesis investigates neural computing applied to electrical power plant cooling water system forecasting. The target system is a coal-fired, base-load electrical power generation facility owned and operated by the Tampa Electric Company in Apollo Beach, Florida. During the process of converting chemical energy contained in coal to heat energy and finally to electrical energy, excess heat energy is created and must be dissipated. The excess heat dissipation occurs by way of Tampa Bay, a large body of salt water directly navigable to the Gulf of Mexico.

The Environmental Protection Agency has established water temperature discharge guidelines and restrictions in order to protect the surrounding habitat. Current plant operations dictate unwritten heuristic approaches used to reduce the opportunity for temperature violations. The value in this work is twofold. First, the study attempts to uncover features that affect the water temperature as it leaves the Big Bend facility.  These features, once identified, are then used to understand the characteristics of the plant as they relate to the water temperature discharge.

Neural computing techniques are used in this study because most of the variables  exhibit interactions that are difficult to discern and categorize through other approaches. The pattern recognition facility of neural computing is especially important to this investigation. Intermediate neural network architectures are designed for proving specific feature interactions, and these models contribute to the final system architecture mostly by demonstrating preprocessing requirements.

The resulting artificial neural network architecture and associated preprocessing accommodates time delay features and produces results to within 1.0 degree Fahrenheit.  The final architecture is a Cascade Correlation hidden layer model, composed of 28 input nodes and 1 output node.