WordPress is an incredible Content Management System — and it is free! But WordPress off the shelf is just that — a content management system. The best part of WordPress is that it is extensible! Continue reading “WordPress Plugins”
Let me ask you a question. Would you rather be doing business with “email@example.com” or “firstname.lastname@example.org” ? Which one looks more professional? Which one looks more trustworthy?
Now that you have your web site configured, it is time to configure your mail agents to send “as” someone from your domain. This increases the value of the emails you send.
Every decent evaluation starts with some type of criteria. This evaluation is no different! Here are a few artifacts that we’ll be reviewing.
In this article, we are only going to be considering mail relays that offer free long term plans. Companies that provide “test” accounts that are limited to some fixed number of days or some fixed number of total emails may be listed, but immediately discounted. Only companies that offer “free” plans will be considered. For example, companies that offer “the first 10,000 messages per month” will be included.
No odd headers or footers in the free plan
Some companies will provide a relay if and only if you allow them to brand their own company on every one of your outgoing emails. While this may be okay for your specific circumstance, it is generally a bad idea.
No unreasonable limitations on sending emails
After reviewing one of the companies, I found it necessary to updated the “acceptable relay” criteria. This is one of those additional criteria. What happened is that one of the mail relay companies said that “personal” emails were not part of their core business. In their opinion, using their mail relay to send emails to your friends and family is outside the scope of a mail relay’s accepted use. Instead, only “Transactional” and “Bulk Marketing” emails are allowed.
To explain a few terms that you may run into while looking through the different mail relays, here’s a few definitions.
- Transactional emails are based on transactions initiated by a visitor. According to Wikipedia, “Transactional emails are usually triggered based on a customer’s action with a company. To be qualified as transactional or relationship messages, these communications’ primary purpose must be “to facilitate, complete, or confirm a commercial transaction that the recipient has previously agreed to enter into with the sender” along with a few other narrow definitions of transactional messaging”
- Direct emails (which may also be known as Bulk, Marketing, Commercial emails) are “sent in bulk … to family, friends, subscribers and customers such as party invitations, group messages, forwarded messages, announcements, newsletters, promotions, marketing tools and tips, classified ads, and direct email marketing campaigns. “
Software as a Service “cloud” offering
An additional criteria for the mail relay is to be completely cloud based, with no installed portion of the application. Why? Because the cloud is the future. Trust me in this, you want to focus on your business, you do not want to be distracted by managing the servers and infrastructure required to do this on premise. For what it is worth, I recommend cloud based services for everyone. For more information on “The Cloud”, check out this article.
Relay Candidates and initial findings
Finding candidates was easy! Finding acceptable candidates that had reasonable “free monthly” plans was equally easy, just a little more time consuming. Testing each of the candidates proves somewhat time consuming. It takes awhile to configure the relay, to configure your mail client, to get used to the specific user interface, and to send a sufficient number of emails to make the test worthwhile.
That all said, I started my search in the typical manner, with a google of “free smtp relay”, and went from there. As time goes on and more specifically I find limitations with a company, I’ll add to the list.
SendGrid — Not recommended
SendGrid was at the top of the SEO list because they pay for placement. Certainly, paying for advertisement may make a compelling reason to test the product. Let’s see what you get for free.
The free plan is 100 emails a day forever. Before I actually took SendGrid for a spin, I decided to look at what some of the other companies were offering for the Free plan. As it turned out, the next few listed in the general Google search were all 200 emails per day for the free plan. Since that is double the number of emails available through the free SendGrid account, I decided to spend my time on one of the other free companies instead.
MailJet — Best so far but now (probably) Not recommended
Mailjet.com was an immediate contender, with
- A promise of 6000 free emails per month (up to 200 per day)
- A fast registration for the free account, with no credit card necessary
- A clean, easy to use interface
- A free SPF & DKIM test and configure utility
- Free “email tracking” that monitors Sent, Delivered, Opened, Clicked, Bounced, Blocked, Spam reported, and Unsubscribe requests
About a week into testing, I noticed almost all emails were delivered in a timely manner. But, there were two emails that wound up not being delivered. The emails showed up as “sent” and “delivered” from the GUI, but the emails never made it to the destination — not to the primary inbox, nor any SPAM folders.
I consulted the MailJet professional staff, and was told that there was a recent outage that caused problems with some emails, but the issue had been resolved. Okay, hey, all companies have issues from time to time, it just so happened this one particular company had an issue while I was testing. Two emails out of around 100 were affected.
But then the unexpected. The MailJet personnel described that they do not support what they are calling “personal email”. Here’s the response:
A transactional email is an expected message and its content is information that the client wishes to check or confirm, and not “discover”. This means that these email can not manually send by you, it can only trigger from the recipient side.
Common examples of transactional emails:
Shipment tracking and order status
Order shipment confirmation
The email you have sent is considered as personal communication which is not Transactional email. ISPs like (gmail, hotmail, yahoo…) often mark these email as spam as it is not pure Transactional email or Marketing email.
At the moment, Mailjet support two types of emails which are pure Transactional email and Marketing email. We do not support for the personal communication email yet, if you sending this type of email, some of they will have deliver issue.
Although MailJet showed great promise as being a permanent and comprehensive email solution, I cannot recommend them at this time due to two facts.
- First, there were emails that were eventually marked “bounced” although from all indications it had something to do with problems on their mail server that was not fully described. I did ask for more information, but was not provided an answer. I’m unclear what they are doing to prevent the issue from happening again, especially the fact that the emails were marked “delivered” when in fact they later showed up as “bounced”.
- Second, MailJet does not allow sending “personal” email. I will admit, “personal email” was not a category of mail that I understood at the beginning of this writing. I’m not sure if this is going to be an issue with other mail relays. I will certainly explore that with other companies before recommending them.
To wit, prior emails to the same addresses were delivered through MailJet with no problems, and later emails to the same recipients were delivered through MailJet with no problems.
That all said, there is enough concern about the validity of using MailJet as to at least consider other solutions. I’ll be searching for a new solution shortly.
I must say, it wasn’t as nearly as easy as I expected to find a reasonable free SMTP Relay.
As of this writing, I am not recommending MailJet, only because the MailJet team has identified their servers are not to be used for “regular” mail. I have an open ticket with them trying to figure out (1) what happened with the email failures early on in the testing, and (2) what is going on with their recommendation against using their service for “personal” email.
I’ll be searching for other mail relays in the coming weeks, and I’ll keep you posted on my progress!
- “This test will list MX records for a domain in priority order”, http://www.mxtoolbox.com
- “Build Your DMARC Record in 15 Minutes”, https://blog.returnpath.com/build-your-dmarc-record-in-15-minutes-v2/
- “DMARC Deployment Tools”, https://dmarc.org/resources/deployment-tools/
- “How to Setup DMARC records in cPanel”, http://www.inmotionhosting.com/support/email/fighting-spam/dmarc-setup
- “DMARC Check”, https://stopemailfraud.proofpoint.com/dmarc/?lookup=marksatterfield.com
First, there was the data center and time shared compute engines. Then there was distributed computing to the desktop.
Today, discussions of cloud computing is all the rage.
Be it Microsoft’s Office365, Amazon Web Services (AWS), Google Cloud Platform, or one of the many on site offerings, Cloud Computing is here to stay. This article will begin by exploring some of the many cloud computing advantages and disadvantages (for there are some!). Next, we’ll define the three primary “as a service” solutions. Finally, we’ll apply Cloud Computing architecture and describe how “the cloud” can be used by real live businesses.
Advantages of Cloud Compute models
- On-demand. In Cloud Compute models, the services are “on demand”. This means that instead of having to rent a physical location, apply for permits, purchase physical servers, standing up those servers in a physical data center, and hiring engineers and staff to run the data center, the Customer can focus on speed to market and stand up the cloud on demand. This allows the equivalent of “leasing” equipment, instead of forcing large capital outlays.
- Rapid elasticity. In Cloud Compute models, services can be expanded rapidly, and disposed of just as rapidly. This reduces the concerns for oversizing or undersizing equipment purchases.
- Business Continuity Planning and disaster recovery. Cloud compute offers location abstraction, where the Customer does not have need to control the geographic deployment area. That said, if properly deployed, Cloud Computing models provide most of the computing infrastructure required to solve business continuity (BCP) and disaster recovery — all built into the deployment. That is, multiple geographically distributed compute solutions can be deployed, all without standing up independent physical locations. Although this does not solve the entire Business Continuity plan (click here for a more comprehensive discussion of BCP), it goes a long way in the right direction.
- Security. The Host company provides the physical security to the servers and datacenter. Depending on the solution, the Customer is responsible for various levels of data security.
- Improved mobility. All forms of cloud computing offer improved mobility for the workforce by centralizing the compute stack into a remote addressable solution. There is no longer a need to create and protect a DMZ – if your employees have an internet connection, they’ll have access to the CSP.
Disadvantages of Cloud Compute models
The cloud compute model is highly effective, and there are many reasonable advantages of moving to a Cloud Service Provider (CSP). That said, there are disadvantages to any solution, and CSP is no different. As with any solution, it is important to consider the CSP risks before fully embracing the architecture. Here we’ll explore some of the disadvantages.
- CSP Outages. Unfortunately, like all cloud stacks, cloud providers also suffer outages. If an outage does occur, the Customer may feel helpless in relying on the CSP in bringing the system back online. That said, Outage risks can be overcome by building multiple cloud stacks with multiple CSP’s providing distributed geographic deployment.
- Network outages. Network outages do and will occur. In a purely on site solution, Internet Service Provider (ISP) failures do not impact the business. However, in a cloud solution, the ISP is a primary point of failure. To manage these risks, multiple ISPs can be employed.
- Security. While CSP’s offer tremendous Security value, there is a risk that policies are not followed. Depending on the type of business you are running, some of those risks can be transferred by way of contractual language such as Business Associates Agreements in a healthcare environment.
- Vendor lock in. Vendor concerns exist with shrink wrapped software, and even more concerns exist for cloud services. The customer must always be cognizant of vendor lock in risks. For example, the customer should have mitigation plans in place if a vendor goes out of business, or if a contract ends, or if the contract becomes unaffordable. These plans should be tested on a regular basis to confirm that all data is recoverable and the business is able to continue unabated.
Types of “As a Service” solutions
Although there are many different marketing descriptions, there are three primary “As-A-Service” cloud compute service models. Here are the three models.
- Infrastructure as a Service (IaaS). Infrastructure as a Service is the most basic “as a service” model. IaaS is a solution where the customer is provided the ability to provision processing, storage, networking, and other basic computing components. The consumer does not control the underlying cloud infrastructure, but does control the operating system and applications. The Hosting company controls the data center including physical access to the infrastructure, heating and cooling, insurance, and other infrastructure costs.
- Platform as a Service (PaaS). Platform as a Service is a solution where the Customer is controlling the platform from the point of view of the Operating System. In PaaS solutions, the Hosting company provides a Platform Deployment Template (or a selection of templates). For example, a PaaS hosting company may provide templates for Windows 10 or Linux with a specific number of CPUs, specific amount of RAM, and specific hard drive capacity. The Customer has full control over, and full responsibility, for configuring the Operating System and any associated applications.
- Software as a Service (SaaS). Software as a Service is the most controlled “As a Service” solution. In this environment, the Customer is purchasing access to a software package that is hosted on the Host company’s platform and infrastructure. Typically, the SaaS solution is accessed via a web interface, or deployed application. Configuration of the SaaS is limited to configurations within the software itself, not associated with the Platform (the operating system) nor the Infrastructure (for example the number of CPUs). If there are speed considerations that are purchased, the speed considerations are related to artifacts such as “Transactions per Second” instead of the number of CPUs.
Real life examples
We’ve covered Advantages and Disadvantages of Cloud Service Providers. Now lets explore where these CSP solutions can be beneficial.
- Say, for example, you own a retail store. You regularly serve 100 customers per day, but on Black Friday your customer base expands 10 fold to 1000 customers. Through a CSP model, you can rapidly expand the services to handle these additional customers for those days, then tear down the services after the rush. There is no need to purchase hardware and deploy it in your own data center, just lease the engines to accommodate the surge.
- If a business is wrestling with the risks and unknowns of building out a full data center, it may be more reasonable to stand up cloud services as are necessary. In this way, the business owners can focus on the business instead of managing a data center and the staff to maintain it.
- In a SaaS environment, a business does not have to be concerned with regular software updates. Instead, the CSP host will maintain the SaaS environment, and the business can focus on the business needs. Security risks are also reduced since the most recent software package is regularly deployed.
- If a business experiences a recession or other cut backs, the cloud expenses can quickly be reduced. Due to rapid elasticity, the business is not at risk of purchasing and maintaining large unused data centers.
Where to go from here
As with any solution, it is a good idea to outline the specific benefits and concerns that you will have as you explore cloud computing. As a recommendation, I’d say jump to Cloud earlier rather than later, but be confident that the risk plans are defined and managed appropriately for your business.
Reach out to me with any specific questions. As always, let’s be careful out there!
Key acronyms and technologies
- AWS – Amazon Web Services
- CSP – Cloud Service Provider
- ISP – Internet Service Provider
- SaaS – Software as a Service
- PaaS – Platform as a Service
- IaaS – Infrastructure as a Service
- “The NIST Definition of Cloud Computing“, http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf
- “Advantages and Disadvantages of Cloud Computing”, http://www.levelcloud.net/why-levelcloud/cloud-education-center/advantages-and-disadvantages-of-cloud-computing/
- “Google Cloud Platform”, https://cloud.google.com/products/
- “Benefits of cloud computing”, https://www.ibm.com/cloud-computing/learn-more/benefits-of-cloud-computing/
- “11 Advantages of Cloud Computing and How Your Business Can Benefit From Them”, https://www.skyhighnetworks.com/cloud-security-blog/11-advantages-of-cloud-computing-and-how-your-business-can-benefit-from-them/
- “Cloud Computing and Is it Really All That Beneficial?”, https://www.lifewire.com/cloud-computing-explained-2373125
- “Why Move To The Cloud? 10 Benefits Of Cloud Computing”, https://www.salesforce.com/uk/blog/2015/11/why-move-to-the-cloud-10-benefits-of-cloud-computing.html
Have you notice that WordPress saves post revisions for you? It is a great utility!
Try it out yourself. Edit a post, click “Update”, and voila, you have Post Revisions!
But sometimes, post revisions can seem to get out of hand. Do you really need or want hundreds of revision histories?
Well, WordPress is here to help you.
First, let me mention that revisions take up space — usually a lot of space. Each revision is held as a separate entity within the database. Therefore, unlimited revisions is usually not a great idea. But having revisions is usually a very good idea, as you may already know.
There are a few settings available to modify how WordPress will be handling revisions for you. They are all contained in the wp-config.php hosted in the main directory of your WordPress instance.
Defining the number of revisions
Revision count is set in the line
define( ‘WP_POST_REVISIONS’, REVISIONS );
Where REVISIONS is
- true or -1: This is the default option in WordPress. WordPress will store every revision of every post
- false or 0: This eliminates all revisions. The only version retained is the most recent saved version.
- Any number greater than 0: This limits the number of revisions to a specific number and automatically deletes all other revisions.
Defining the Autosave interval
WordPress will automatically save posts for you after a defined number of seconds.
define( ‘AUTOSAVE_INTERVAL’, SECONDS ); // Seconds
Where SECONDS is interval at which an autosave will occur.
A word of warning.
Optimally, you may think that setting AutoSave to a very low number of seconds is the best! This would mean that even if the power goes out or the Internet becomes unavailable, you haven’t lost any work. And this is true!
But consider this also, each version that is AutoSaved potentially takes a lot of space. This might not be optimal.
So then you might consider, okay, just make the REVISIONS a reasonably low count, and your site will be fine again! Well, maybe. Consider it this way. If REVISIONS is set to say 15 (which sounds like a reasonably high number), and AutoSave is set to 60 (seconds), then regardless of whether you have explicitly saved a copy of the page, the revision history disappears after fifteen minutes.
That might not be optimal for you.
I don’t have a magic answer for you here, other than to say, be aware. For me, I’ve set my AUTOSAVE to 120 seconds (I normally save more often than this). and I’ve set my REVISIONS to 50. In my case, I’m running my own server farm, and I have potentially unlimited database space, so retaining many revisions is not a big deal. Your situation may be different.
No matter where you live, you’ve probably heard about the many breaches of data that have occurred over the last few years. Just to name a few (and no, I’m not singling out any particular companies): Continue reading “Help I’ve fallen and my identity has been stolen!”
Branding, Searching, Buying, Building… You are likely here because you want your very own domain name. That is great news, and I’m here to help!
A domain name (also known as a URL, Uniform Resource Locator, or web address), is the unique way for the world wide web to know you. Each URL is a branding, a brand name where others can find you. Inasmuch, the brand should be unique, and memorable.
Consider, what are you tying to convey? Is it that you want people to find you as a person, or is it that you are selling something? Ideas for branding might include:
- Your name. Like this domain, marksatterfield.com, it is my name. It might be unique enough, and descriptive enough for everyone to find you. But it might not be exactly what you are looking for, and it might not be unique enough for other people to find you. If your name is a common name, it is likely already taken. If your name is Mark Satterfield? Yes, the domain is already taken. Sorry about that!
- Your nickname. This might be an acceptable domain name, depending on how common your nickname is, and whether it is available.
- Have you started a company? Then use the web address associated with your company.
- Are you selling a book or product? Then use the name of the book or product in your web address.
The next few steps are going to be iterative. You are going to dream up the ideal name, only to find out that your ideal name is already someone else’s ideal name and registered. Then you’ll have to dream up a different ideal name.
Searching for your domain name
A registrar is a company that is authorized by ICANN to register domains. Once you have a few ideas for a domain name, you’ll next have to check if the domain is available. This is a bit tricky. if you search for a domain on the wrong registrar, the registrar might hijack and camp on your domain! Although no one can prove this happens, I’ve searched for names on GoDaddy, only to go back in the next day or two to find out the domain is then taken.
My recommendation is to use internic.net for domain searches. Go to the whois page on internic.net, and enter your choice of domain. For example, enter “godaddy.com”. Be sure to use the Top Level Domain nomenclature (the .com, or whatever else TLD extension you’ve decided to use).
If you receive a No Match message, that means your domain is available! If you receive anything else, that means your domain is not available and you’ll have to go back and search again.
Buying: Registering your domain
Next comes the registration process. Be careful with unscrupulous registrars who might register the domain in their own name. I’ve used several domain registrars and have not had a problem. Google is actually a domain registrar, but other than Google I don’t want to recommend any particular ones here just in case you have an issue.
Building: Setting up your web site
This part gets a little more complicated and beyond the scope of this article.
If you have special requests, or you’d like to have a domain registered and site set up and configured, please reach out to me and I’ll help you out.
Is your phone stuck in reboot mode for no apparent reason? Maybe there is a reason, and there may be a simple fix to it too.
Power button stuck? Let’s check for that!
If your phone looks to be in a “bootloop” where the phone starts to boot, then shuts itself down, then starts the boot process again, it might be caused by a faulty power button.
Here’s a test. Push and hold the power button. Just hold it. Does it appear to have the same behavior of boot looping? If so, then it is likely a power button failure.
If it is exhibiting a different behavior when you push and hold the power button, it could still be a power button failure. Especially if it boots up fully while pressing the button, it is likely a power button failure. Why is that? Because, it should be rebooting constantly with the power button pressed in. If it is not, then there is a contact issue.
Whether our family member gets their credit card number stolen, or our friend gets their Facebook account hijacked, or we have our web site blacklisted for SPAM, we are all affected by phishing attacks — some worse than others.
This is a short discussion of Phishing
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.”
- ARPANET, http://en.wikipedia.org/wiki/ARPANET
- History of the Internet, http://en.wikipedia.org/wiki/History_of_the_Internet#Three_terminals_and_an_ARPA
- Morris Worm, http://en.wikipedia.org/wiki/Morris_worm
- CERT is a Registered Trademark of CMU, http://www.cert.org/incident-management/csirt-development/csirt-faq.cfm?
- CERT/CC, http://en.wikipedia.org/wiki/CERT_Coordination_Center
- CMU, http://en.wikipedia.org/wiki/Carnegie_Mellon_University
- ARPA/DARPA, http://en.wikipedia.org/wiki/DARPA
- Computer Worm, http://en.wikipedia.org/wiki/Computer_worm
- SEI, http://en.wikipedia.org/wiki/Software_Engineering_Institute
2014 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
Now 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
Exploiting 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:
- (development) The development team creates software
- (initial deployment) The software is distributed to end user teams
- (installation) The software is installed by end user teams
- (feedback) The development team is made aware of requested upgrades and security issues.
- (patch development) The development team creates patches
- (patch deployment) Patches are distributed to end users
- (patch installation) End user teams install the patches
- (repeat) Repeat to Feedback loop
- (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:
- 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.
- 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.
- 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.
- 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
To 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.
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.
- NIST SP 800-30, “Risk Management Guide for Information Technology Systems”
- Heartbleed SSL vulnerability, https://en.wikipedia.org/wiki/Heartbleed
- US-CERT Alert on Point of Sale exploitation, https://www.us-cert.gov/ncas/alerts/TA14-002A
- Shellshock vulnerability, https://en.wikipedia.org/wiki/Shellshock_(software_bug)
- Google’s Project Zero, https://en.wikipedia.org/wiki/Project_Zero_(Google)
- Microsoft Patch Tuesday, https://en.wikipedia.org/wiki/Patch_Tuesday
- Defines Zero Day Vulnerability, “A zero day vulnerability refers to a hole in software that is unknown to the vendor”, http://www.pctools.com/security-news/zero-day-vulnerability/
- 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”, http://netsecurity.about.com/od/newsandeditorial1/a/aazeroday.htm
- Zero Day Vulnerability, “A zero-day vulnerability is previously unknown vulnerability in a software”, http://www.thewindowsclub.com/what-is-vulnerability-in-computer-security