by Dwayne Stewart
3:35 min read | Audio
Implementing all the CIS controls won’t guarantee there will never be a successful attack on your systems. Sooner or later, someone could penetrate defenses and access confidential information or deposit malware. To be prepared, you need an incident response plan, the focus of CIS Control #19.
Have a plan in place
Figuring out how to manage incidents as they occur is bad practice in general and ultimately not in the best interests of your organization. Speed is of the essence, and to minimize service disruptions, a plan should be in place and people prepared to execute that plan.
Steps to take in response to an incident should be delineated. A list would include something similar to this:
Each step will include detailed instructions on what to do in the various situations that may occur. The more thorough the plan, the more efficient the response.
Assign duties and roles
To carry out a plan effectively, an incident response team should be created, consisting of staff that are familiar with the plan. They understand what's expected of them and who will be making decisions. Each team member’s role should coincide with their position within the organization.
The decision-making authority needs to be clear. This allows for prompt response to a discovered breach, as opposed to lengthy discussion about who should do what. Emergencies are generally unpredictable, so one or more levels of backup authority are needed. The less time it takes to find someone who can initiate and direct action, the easier it is to mitigate the issue.
The response team needs to have the skills and training to deal with situations under pressure. There are far more kinds of attacks than any person can be familiar with, so familiarity with mitigation tools and processes, as well as good problem-solving skills, are important.
Establish reporting procedures
A quick response requires getting information to the right people quickly. Both software and people play a role. The proper tools need to be in place that provide network visibility and appropriate notification of malicious or anomalous network activity. For example, intrusion detection and endpoint protection software should issue alerts when suspicious activity is detected. Logs from all network infrastructure devices and network security controls should be collected and analyzed by a SIEM or other log management utility. This provides a single pane of glass that should allow logs to be used in providing a clear, concise picture of what has occurred.
In addition, employees need to know how to submit a report if they see something unusual that could be an indication of a compromised machine. There should be report forms so that people will provide as much useful information as possible. They should have entries for the system affected, the symptoms, the date and time, and the actions taken before and after noticing the incident.
Contact information needs to be included in the incident response plan so that members of the response team can be contacted immediately once an incident is confirmed. The information needs to be up-to-date in order to avoid delays.
There can be very long periods between security incidents, and members of the incident response team can't afford to forget how to perform their duties. They need to perform well under stress, even if they don't do it often. Periodic exercises will help them to remember what they need to do and to avoid confusion and prevent simple mistakes when responding to an incident. They'll also help to make sure all the necessary information is still valid. Something as simple as an outdated phone number can seriously slow remedial action.
"Be prepared," is famously the Boy Scout motto. That state of readiness applies to intrusions and breaches, too. The response needs to be planned, organized, and smoothly handled. A well-secured site will encounter few such situations, but it takes only one to cause major data loss, financial damage, and loss of trust. Properly managing security incidents once discovered can help minimize their impact and ensure an organization's continued survival.
by Perry Lynch
3:35 min read | Audio
Flaws in software can leave your information systems vulnerable to attacks. Information about bugs in popular commercial and open-source software is available to everyone. Attackers exploit them once they're known, so keeping up with patch releases is essential to security. Applications that are developed in-house and commercially obscure applications aren't subject to the same broad scrutiny, but they still may have potentially vulnerable coding flaws to be dealt with. CIS Control #18 addresses the methods of keeping applications secure, whether they're acquired or internally developed.
When it comes to vulnerable applications, the source doesn’t matter. When dealing with applications from outside sources, whether commercial or free, the most important consideration is to stay with a supported version and apply all security patches in a timely manner. This doesn't necessarily mean having the latest version! When available, using the long-term support (LTS) version of an application can be less disruptive than updating to each new version. However, regular bug fixes and security patches still need to be applied quickly, and you should have an upgrade plan ready when the newer version is released.
In many cases, by the time a security patch is released, the vulnerabilities that it addresses are publicly known. Publicly-available exploits for the code may already exist or be easily discovered by reverse-engineering the change. Criminals will figure out how to take advantage of it if they haven't already. There's no escaping the need or the urgency required to fix these vulnerabilities.
Developers need to design security in from the start, not add it on after they have working code. Unfortunately, this remains a recommended practice and not a common one, so organizations that develop their own applications may have a lot more work to do.
There's pressure to get the code working on time, which sometimes results in security considerations being pushed to the background. Yielding to the pressure will only cause trouble. It's harder to go back and catch every vulnerability than it is to stick with security-oriented development practices that minimize the chances of exploitable bugs.
The practices which bake security in from the start include these:
Considerations for all applications
Development and QA work should be done on development systems that don't have access to production data. Developer accounts shouldn't give access to production systems; that way no one can work on live data by mistake.
Developers can still miss bugs, and configuration errors can introduce vulnerabilities. To maintain the safety of your applications and data, organizations should always test new implementations of the applications they use with automated scanning software. Being the first to discover a bug is better than living with an undiscovered vulnerability.
Code should go to production only after being thoroughly tested. A full, automated test needs to be run before each release, not just on the changes. Bugs in earlier versions have a way of creeping back, and seemingly inconsequential changes can introduce problems.
If any new or previously undocumented vulnerabilities turn up, they should be carefully documented so that others can replicate them. A confidential report should then go to the software's maintainer. Until it's fixed, measures should go into place to prevent exploitation of the bug. These could include input filters or a configuration setting to avoid the dangerous use case.
Application firewalls are another important level of protection against unknown or unpatched bugs. They provide a level of protection against the exploits of known bugs and common attack patterns, such as syntactically incorrect requests.
OWASP has some excellent resources for developing secure applications.
The stakes are high
A previously undiscovered bug can turn into an active threat without warning. Zero-day exploits take advantage of these to steal vast amounts of data or gain control of computers. Criminals or malicious attackers will have information about these vulnerabilities before you do.
Badly designed and out-of-date applications are especially at risk. Protective measures need to cover purchased, free, and in-house software. They need to guard not only against known issues but against ones that are still unknown. A multilayered approach consisting of good design, maintenance, and application-level protection against malicious traffic will provide the best protection.
by Perry Lynch
3:20 min read | Audio
Security Awareness Training is one of the most cost-effective ways to improve your organization’s overall security posture. Most breaches are at least partly due to human error, and while nothing can be done to completely eliminate errors, a good training program will reduce greatly the potential for security-related mistakes. CIS Control #17 covers the basics of a reliable program and what a good one should do.
The starting point is a skills gap analysis. What skills does each person need to stay clear of dangers, and where do they fall short? Everyone needs to understand the basic points such as setting strong passwords and being wary of spam. People with access to sensitive systems need to be and stay aware of subtler points--such as personally targeted phishing and inappropriate information sharing.
Security programs need to identify and focus on the areas of greatest risk. This applies as much to training as to network configuration or software updates. In this case, focused training is crucial to strengthen areas where technical solutions alone are not enough.
Anyone with access to a network can make a mistake and create problems. So along with training, additional technical measures need to be implemented. The organization should follow the recommendations of Control #14 and only grant users limited access to those rights required to perform their jobs. Those with higher levels of access need to be especially alert.
Any training program needs to produce measurable results; otherwise there's no way to measure a program’s effectiveness. There should be a focus on specific goals and closing the skills gap. Training should target the most serious risks associated with each individual's role. One example--people with root access should learn how to protect those credentials and to minimize their use of root accounts.
Security awareness is the understanding of methods which would-be intruders use to deceive people. These techniques keep changing, so users need periodic updates. All employees should study security awareness materials, and management needs to confirm this is accomplished. Senior management has to be included in the training. They continue to be the favored targets of personalized deceptions because they are more likely to have access to sensitive information as well as financial accounts.
Regulatory changes, such as GDPR, may require a new set of priorities. Changes in the information an organization handles may shift the greatest areas of risk. Any awareness training program needs to be able to adapt to properly communicate the risks involved.
Mentoring by more experienced users is often an effective approach. They know better than anyone else where the risks are, and hopefully they have good rapport with the people they're training.
Social engineering exercises should be conducted periodically to assess the current level of users’ awareness, reinforce recent training activities, and to make sure people don't fall back into carelessness.
The most important consideration of security awareness training isn't that people give the right answers on a quiz--the goal is to help them instill habits that prevent errors and do the right things in practice consistently.
An ongoing program
The most effective awareness programs include routinely-communicated messages from the security team. A regular cycle of policy reminders, educational messages, risk warnings, and messages about current security news will easily keep your staff more involved and alert to potential threats.
You can ensure that users are paying attention by including occasional security advice that can assist them personally, and by occasionally naming the front-line heroes--those who have first recognized a security threat and promptly reported it to the help desk and/or security team.
With ongoing security education, people will learn to avoid the mistakes that can lead to disaster. People will always make some mistakes, but ingrained security habits will prevent the most common and most serious ones.