Security Essentials
Networking Concepts
Network Fundamentals
“The key tenet of network security is to know thy system. You cannot secure something that you do not understand or know how it works.”
Security requires not simply doing good things, but doing the right things. Offense guides the defense. We don't want to fix random vulnerabilities; that's doing good. We want to fix the vulnerabilities that the adversary is taking advantage of; that's doing the right thing.
Before you spend a dollar of your budget or an hour of your time in the name of security, answer three questions:
{C}1. What is the risk?
{C}2. Is it the highest priority risk?
{C}3. Is it the most cost effective way of reducing the risk?
Encryption does not equal security. Many organizations make a lot of mistakes.
“Once someone has access to information they potentially represent an insider threat.”
Nobody knows everything. If anyone claims to know everything about information security then they're lying to you.
Redundant data centers should be located far enough apart to mitigate the risks associated with large-scale disasters (i.e. natural disasters, nuclear disasters, acts of war).
Multiprotocol Label Switching (MPLS)
There are no international borders on the Internet. Traffic may be routed outside of the country of origin even if the destination is located in the same country as the source. Relevant Link: Repeated attacks hijack huge chunks of Internet traffic, researchers warn
How are your devices connected? How does information flow in and out of your network? Do you have an accurate, up-to-date network diagram that you can validate on a regular basis?
Are you utilizing what you've already bought?
- 802.1x
- Network Access Control (NAC)
Most switches support 802.1x and NAC. Use what you have!
Use NAC and 802.1x to limit and control access.
Use Port Security where appropriate. Use 802.1x in conference rooms and similar shared spaces to allow employees to connect their company-owned systems to the network.
Segment LANs using VLANs. Filter traffic moving between VLANs.
Use NAC to dynamically assign connected systems to VLANs.
Create levels of trust.
Example
Level 5 - Full* Access (*Limited by Role)
Level 4 - Full* Access Less Sensitive Data Repositories (*Limited by Role)
Level 3 - Basic Internet Access; Minimal Access to Internal Servers
Level 2 - Internal Access Only; No Internet Access
Level 1 - Complete Quarantine
Typically, when a system is compromised, there is an increase in the number of connections, an increase in the length of connections, an increase in the amount of data being transferred, and a change in the destinations being contacted by the system. So what is normal? If there is a deviation from normal then NAC should reassign the system to a VLAN in a different level of trust. When a system exhibits bad behavior, take away access. When a system exhibits good behavior, or no longer exhibits bad behavior, allow/re-allow access.
Are you using the resources available to you in the most efficient manner? If you don't have enough staff, and you purchase additional software/systems/solutions, you're making the problem worse because you have more systems to administer, and you're not adequately staffed to maintain those systems. Maximize your current investment.
DMZ
- Systems are high risk and low trust.
- All systems that are accessible from the Internet should reside in the DMZ
- Systems never contain sensitive data.
Private Network
- Systems are high trust and low risk.
- All systems that contain sensitive data should reside in the private network.
- Systems are never accessible from the Internet.
DMZ systems should only communicate with private network systems via an application proxy located in a middleware tier. The middleware tier is essentially another DMZ. It's the DMZ for the DMZ.
A single firewall with multiple interfaces will suffice to separate the Internet, the DMZ, the middleware tier(s), and the private network from one another in the architecture described above.
Review your general network architecture, and confirm that all systems that are accessible from the Internet are on the DMZ and DMZ systems do not contain sensitive data. Confirm all systems containing sensitive data are on your private network, and private network systems are not directly accessible from the Internet. Confirm that DMZ systems can only communicate with systems on the private network via a middleware proxy. If additional security is required, add additional middleware layers.
If you allow someone from the Internet into your private network, all bets are off.
Web servers should not also host their respective database instances.
Outlook Web Access (OWA) can be configured using the architecture described above.
IP Concepts
Classless Inter-Domain Routing (CIDR) Notation
Address Resolution Protocol (ARP)
ARP is vulnerable to ARP cache poisoning attacks (a.k.a. ARP spoofing). The attacker must be on the local network in order to perform this type of attack.
The first method used in an attempt to resolve a FQDN to an IP address is the local operating system's host file. The local host file should only be writable by root. If a remote employee is using an untrusted network to connect to organizational resources, their host file should include entries for the organization's VPN service and any other critical services hosted by the organization. This prevents a compromised DNS server from incorrectly resolving the respective host names of the services.
The second method used in an attempt to resolve a FQDN to an IP address is Domain Name System (DNS). Do you know which authoritative name servers are listed for your organization's domain names? Only current, production name servers should be listed.
When reviewing logs, domain names are more useful than IP addresses. Domain names can often be determined from IP addresses using reverse DNS lookups. Doing reverse lookups in real-time can be resource intensive. If reverse lookups are not performed in real-time, there is a greater risk that the query will return incorrect/outdated information.
Keep DNS software up to date.
When do your domain names expire? Who is responsible for re-registering and maintaining your organization's domain names?
Split-horizon DNS should always be used. External DNS servers should be located in the DMZ. Internal DNS servers should be located in the private network. External DNS servers should not be recursive for any domains other than your own. If recursion is required, a separate set of inbound DNS servers, located in the DMZ, should be used. External DNS servers should be non-authoritative. Limit zone transfers to trusted non-authoritative servers.
In IPv6 when using address auto-configuration, the MAC address is used to make its public IP address unique, exposing the type of hardware used and providing a unique handle for a user's online activity.Source
Ensure all endpoint security products in use support IPv6.
Internet Control Message Protocol (ICMP)
Only allow the minimum amount of ICMP control messaging that you require; block everything else.
Protocol Analysis
The best way to sniff traffic on a switch unauthorized is to use ARP cache poisoning. The target host's cache should be poisoned such that its traffic is sent to the sniffer instead of the destination. The traffic can then be forwarded to the destination after it has been sniffed. It's easier to manipulate a client than it is to manipulate a switch.
NTP should be implemented on your network.
One (1) hexadecimal character represents four (4) bits. (4 bits = 0.5 bytes = 1 nibble)
Decoding an IP Header
The Internet Header Length (IHL) is the number of 32-bit words in the header. To convert the IHL to bytes, multiply the IHL by 4.
ICMP = 1 (0x01)
TCP = 6 (0x06)
UDP = 17 (0x11)
Decoding a TCP Header
The Data Offset specifies the size of the TCP header in 32-bit words. To convert the Data Offset to bytes, multiply it by 4. The minimum size is five words (20 bytes), and the maximum size is 15 words (60 bytes). The field gets its name from the fact that it is also the offset from the start of the TCP segment to the actual data.
Virtual Machines
The hypervisor should be locked-down to the greatest extent possible; unnecessary services should not be running.
Take snapshots often when working in a test environment in order to reduce the amount of work necessary to recover from a mistake.
Safety and Physical Security
If someone can gain physical access to a system or a network, all bets are off.
Physical security measures should not compromise the safety of an organization's employees, customers, etc. Safety will always trump security.
Do you know where the emergency shut-off valves or switches for gas and electricity are located? Who would need to be contacted in the event of an emergency? Do you know where all emergency manual overrides are located for all uninterruptable power supplies, fire suppression systems, cooling systems, etc.? Does everyone at a given location know or have access to the information they might need in an emergency? Do domestic employees know what number(s) to call in case of an emergency while they're working in a foreign location? Do foreign employees know how to contact emergency services while they're working in the United States? Local emergency contact information can be located on the back of employee / guest badges.
Does everyone in your organization understand the evacuation plan(s) for their given location? Are your organization's evacuation plans tested on a regular basis? Evacuation routes should be posted. Meeting points should be clearly communicated and located clear of danger. Employees should be trained to rapidly secure sensitive information and leave. Drills should be taken seriously. Define evacuation roles.
Electrical circuits should be monitored to ensure that they are not overloaded. Redundant power supplies should be connected to separate circuits. Power and cooling systems should be regularly audited to ensure they're capable of providing adequate capacity.
Visitors should be escorted at all times, and kept away from areas where they may gain inadvertent access to sensitive information (information on whiteboards or monitors, overheard conversations, etc.). Offices should be locked when unoccupied.
Are safety and security systems regularly tested?
Defense In-Depth
Defense-in-Depth
There is no single security measure that can protect you. Multiple complementary, redundant security measures need to be implemented in order to create a comprehensive solution. If one security measure is defeated, other measures should be capable of neutralizing the threat. Do you understand the effectiveness of each security measure in your environment? For example, what percentage of the packets that your firewall inspects are dropped? As another example, what percentage of the alerts sent by your IDS are false positives? Security measures should be tuned for maximum effectiveness.
Prevention is ideal, but detection is a must. You cannot stop every attack. If all of your effort is focused on prevention, you're going to lose. When performing an inventory of your security measures, document each device's capabilities. Is it tasked with detection or prevention? Is it operating on inbound or outbound traffic? In order to best protect against the compromise of data, perform inbound prevention and outbound detection. Try to stop them on the way in, but if you're unable to do so then detect them when they leave. Where are the gaps in your security? Are you primarily focused on prevention? If so, implement additional measures that focus on detection. Are you primarily operating on inbound traffic? Implement measures to operate on outbound traffic. Security requires diversification.
Inbound Prevention
Layer 3
- Block known bad IP addresses (e.g. IP addresses associated with botnets)
- Block invalid IP addresses (e.g. private address spaces, localhost)
- If possible, block IP address ranges of countries your organization does not service
Layer 4
- Only allow authorized ports
- Block all unauthorized ports
Outbound Detection
For your organization's network and for each client within your organization, build a profile (using an IDS or SIM solution) that includes the following:
- Average number of connections
- Average length of connections
- Average amount of data transferred
- Typical destination countries
- Percentage of traffic that is encrypted
Typically, when a system is compromised, the average number of connections, the average length of connections, and the average amount of data transferred increases; the destination countries change; and nearly all of the traffic is encrypted.
Before you spend any money or waste any time on security, answer the following three questions:
- What risk are you trying to mitigate?
- Is it the highest priority risk?
- Is your solution the most cost-effective way to mitigate the risk?
Risk is the probability for loss.
Threats x Vulnerabilities = Risk
Threats - What is the offense capable of doing?
Vulnerabilities - What is your defensive posture?
Understand your enemy, and know yourself.
In order to reduce risk, you only have to reduce the number of vulnerabilities. You cannot reduce the number of threats. There are a lot of vulnerabilities. You should only care about the vulnerabilities for which a threat exists. Threats drive the risk calculation. Focus on the most serious threats first; those with the highest likelihood.
Confidentiality - prevent / detect / deter the unauthorized disclosure of data
Integrity - prevent / detect / deter the unauthorized alteration of data
Availability - prevent / detect / deter the unauthorized destruction of data
You can only patch what you know about. Asset management should track installed software. Reduce the attack surface by uninstalling unnecessary software. Patch whatever is left.
Networks should be highly segmented. VLANs should not contain more than approximately thirty clients or approximately fourteen servers.
Do not allow potentially malicious file types as email attachments.
Microsoft Office macros should only be enabled if necessary.
Block HTML email if possible.
Security Policy
A security policy is the foundation of a good security program. A security policy can be thought of as an organization's laws. It should be clear, concise, and specific. It should be readable. It should not be excessively long. It should not be open to interpretation. It should also communicate how the policy itself will be enforced.
If a security policy does not exist, it's more difficult to take action against employee wrongdoing. A security policy protects the organization as well as the organization's employees.
A security policy alone cannot change corporate culture. Stakeholder buy-in is necessary to ensure a security policy's success.
Cookie-cutter security policies do not work. Every organization is unique. A security policy should be customized based on the needs of the organization. An organization's mission statement should influence its security policy.
A security policy should be realistic, not idealistic. The ability to enforce the policy is paramount. Security policies should be reviewed and updated (if necessary) on a regular basis. It should reflect the current state on the environment.
Before creating a security policy, survey the organization's documentation: policies, checklists, procedures, executive memos, etc. Expire any irrelevant or otherwise bad documentation. Determine where gaps exist. Your new security policy should fill in the gaps.
Use version control to manage your organization's documentation; this is especially critical for security policies. Document names should include version and date information. The policy itself should contain version information as well as an effective date. Do not confuse policies and procedures. Policies and procedures are complementary. A policy addresses the who, what, and why. A procedure addresses the how, where, and when. Policies should be read in full. Procedures should be referenced as needed. Policies and procedures should not be combined into a single document.
A security policy should cover the organization's rules:
- Can you use your laptop for personal use?
- Can you use the Internet for personal use?
- Can you install software on your system?
- Can you disable endpoint security / patch management?
- Can you copy data to USB flash drives?
- Can you leave your computer unlocked and unattended?
- Can you share your password(s)?
Procedures should cover the details:
- How do employees request software?
- How do employees change their password(s)?
From the user's perspective, it's best to combine the security policy with the acceptable use policy.
Technology standards and baselines should be created and maintained separately from the security policy. Technology standards are high-level documents that determine what technology can and/or cannot be deployed within the organization. Baselines detail how technology should be configured within the organization.
Policies, procedures, standards, and baselines are mandatory. Guidelines are not mandatory. Guidelines are suggestions, tips, and tricks that help employees adhere to policies, procedures, standards, and baselines. Guidelines should be friendlier and less formal than policies, procedures, standards, and baselines.
A security policy should contain the following:
- Purpose
- What is the risk you're trying to reduce? Why does the organization need the policy?
- Related Documents or References
- Reference procedures, standards, baselines, and guidelines.
- Cancellation or Expiration
- Cancel or expire old policies being superseded.
- Background
- Why is the policy important? To whom does it apply? Be concise!
- Scope
- Policy Statement
- Be clear and concise. Ensure it's specific, measurable, achievable, realistic, and time-based.
- Responsibility
- Who is responsible?
- Action
- Identify penalties for non-compliance.
Is your organization's security policy consistent with applicable laws and regulations? Is it consistent with the organization's mission statement? Is it consistent with other organizational policies? Is it uniformly enforced? Is it current? Is it readily available? Has HR, legal, and management signed off on it? Is it enforceable?
What problem are you trying to solve? Have you determined the root cause of the problem? What risk are you trying to reduce?
What happens if an employee does not follow the policy? There should be penalties for violating a policy. Consistent non-compliance should lead to termination. Collective bargaining terms may apply.
Policy exceptions should be approved via a formal process than includes a risk analysis, and requires a manager to accept the risk in writing. Policy exceptions should expire within a reasonable time frame.
If a non-disclosure agreement (NDA) has not been signed by employees and organizational data is not classified, the data is considered public. Therefore, all employees should be required to sign an NDA.
A business continuity plan (BCP) is a strategic plan that attempts to address potential problems in a proactive manner. The goal of a BCP is to ensure that business processes are not interrupted. A disaster recovery plan (DRP) is a component of a BCP. When business processes are interrupted, the DRP is executed. A DRP is a tactical, reactive plan that focuses on recovery of an IT infrastructure when normal business operations have been interrupted. A BCP is always in effect. You should always be looking for potential problems. You should proactively fix high-priority problems. A DRP is only executed when normal business operations are interrupted; examples include hardware failures, a fire in the data center, and natural disasters.
Identify each business process, and determine how your organization would handle the loss of the process.
A business impact analysis (BIA) outlines the impact to the organization in the event that business processes are not available. It should identify the maximum allowable downtime for each process based on the needs of the organization and its stakeholders. The BCP/DRP should ensure that processes can be restored within the timeframe set by the maximum allowable downtime. Recovering too quickly or too slowly is a problem. Restoring a process with a maximum allowable downtime of 48 hours in 6 hours is a waste of resources, and restoring it in 72 hours is pointless because the organization won't be able to survive. The likelihood and impact of an issue determine whether it's handled proactively by the BCP or reactively by the DRP. High-likelihood, high-impact issues should be handled proactively. Low-likelihood, low-impact issues should be handled reactively.
Access Control and Password Management
Data classification is a necessity when it comes to properly protecting your data. If your data is not classified you can't control it, you can't manage it, you can't track it, and you can't stop it from leaving your organization. Data classification is not easy, but we make it harder than it needs to be. There are three major mistakes that organizations typically make during a data classification project:
- Begin with a complex, multi-tier data classification plan.
- Begin classifying data by assuming all data is unclassified.
- Focus on existing data first.
Use the following guidelines to ensure a successful data classification project:
- Begin with two classification levels: public and private (unclassified and classified). You can further subdivide classified data in a second phase of the project.
- Begin classifying data by assuming all data is classified. Declassify data when appropriate.
- Focus on newly-created data first.
Before anyone can access your system you should identify and authenticate them. Once a user has been identified and authenticated they should only have access to data that they are authorized to access, and they should only be authorized to access the minimum data required to perform their duties. All access should be monitored to ensure accountability. No accounts should be shared. Detailed logging should be implemented on all systems.
Give people the least amount of access they need to do their job, and only give them access when they need it (e.g. Monday through Friday during business hours). For many jobs, the least amount of access required to do the job still poses an unnecessary amount of risk. If this is the case then separation of duties should be instituted. If separation of duties has been instituted, rotation of duties should also be instituted to minimize the risk of employee collusion.
Discretionary Access Control (DAC) grants access to resources at the discretion of the owner or the administrator. A formal approval process should be followed when requesting/granting access to resources. Most organizations use DAC because it’s built into the operating systems in use, it’s easy, and it’s relatively scalable. DAC’s weakness is human error. An administrator or an owner can make mistakes.
Mandatory Access Control (MAC) grants access to resources based on the resources’ classification levels and the users’ clearance levels. Users can typically access resources of equal or lower classification level with respect to their clearance level.
Users should never have administrative access to their systems.
Role-based Access Control (RBAC) grants access to resources based on group membership. Groups map to organizational roles. A user should never be a member of more than one role at any given time.
Managing access is a four-step process:
- Account Administration (On-boarding)
- Maintenance
- Monitoring
- Revocation
Simply because someone needed access to a given resource at some point in the past does not mean they still require access to that resource. Access to resources should expire on a regular basis.
One of the best indicators of a compromised system is a high number of errors related to resource access failures. Users typically don’t attempt to access files they’re not supposed to in the normal course of business.
When an employee leaves the organization, all of their access should be revoked. Accounts should be audited on a regular basis to ensure that former employees no longer have access. Monitor for access attempts by disabled/deleted accounts.
Your organization’s password change interval should be less than the amount of time required to brute force a password that meets the organization’s password complexity and length requirements.
Keep your SAM databases and /etc/shadow files secure. Force NTLMv2 on Windows XP and Windows Server 2003.
Incident Handling Foundations
It’s not a matter of if you’re going to have an incident, but when. Accept that you will be compromised. Strive to identify incidents early, react quickly, and minimize damage/downtime. An incident is an adverse event that interrupts normal operations, or the threat of such an event.
Attackers use a five-phase process when compromising a system:
- Reconnaissance
- Scanning
- Exploit
- Create backdoors
- Cover their tracks
An adverse event occurs during the exploit phase. At this point you must rely on reactive incident response. The threat of an adverse event can be detected during the scanning phase. You should be performing proactive incident response at this point. It is far easier, less expensive, and less resource intensive to perform proactive incident response than it is to rely on reactive incident response.
An event is an observable occurrence in a system or network. Events should be recorded in log files. The log files record the evidence related to an incident. You should implement detailed logging using a consistent time source and event correlation in your environment. An event correlation solution can filter and aggregate events, and assist in root cause analysis.
Incident responders are the first responders. Incidents are high-pressure, high-stress situations. Time is of the essence. Mistakes are very costly. It’s better to move slowly, and get it right than it is to move quickly, and make mistakes. Use pre-designed forms, processes, and procedures to be as efficient as possible, and minimize the chance that mistakes will be made.
Incident Handling requires a six-step process:
- Preparation
- Identification
- Containment
- Eradication
- Recovery
- Lessons Learned
Preparation is the most important, yet often overlooked, step in the process. You need to ensure that you have the resources (people, tools, and support) required to be successful. Set up out-of-band communication methods for use in incident response. If your systems are compromised, and you’re using those same systems to communicate your plans for incident response, your adversary will be one step ahead of you. Never underestimate your adversary. Assume your entire infrastructure is compromised. Setup a shell company that owns domains, mail servers, laptops, and mobile phones for use in incident response; the entire infrastructure should be separate from that of your organization. Obtain the authority from management to take action during an incident response scenario. Management may be unavailable or too slow to act to be effective in an incident response scenario. Decisions should be made in advance, and documented, in order to facilitate efficient execution of the incident response plan. Identify contacts within law enforcement that may be of assistance during an incident response scenario, and form relationships with them. You should not wait until an incident occurs to contact law enforcement for the first time. Determine which approach your organization plans to take when it comes to litigation. Anybody can learn incident response. Skills can be taught. Select team members based on two personality traits: the ability to remain calm under pressure and the ability to work selflessly as part of a team. Incident response causes burn-out quickly. Ensure that team members are well-compensated. Force employees to take (staggered) vacations after major incidents in order to recover and relax. All potentially necessary passwords and all potentially necessary cryptographic keys should be escrowed in a secure safe. Team members may become unavailable during an incident. Provide continuous training. Everything you may need in order to handle an incident should be contained within a jump bag. Your jump bag may (and probably should) consist of multiple Pelican cases. It is better to have it, and not need it than it is to need it, and not have it. Redundancy is paramount.
Be cautious when a potential incident is reported. Communicate with management as soon as a potential incident is reported. Tell them what you know. Provide status updates every two hours. Limit dissemination of information. Incidents should be classified at the highest level of classification within the organization. Deputize the help desk to collect information, and track the extent of the incident. Assign your best incident handler to perform the task of identifying an incident. You must identify an incident without destroying evidence. Your best incident handler should be able to preserve all of the evidence.
Once you’ve determined that it is, in fact, an incident. The next step is to gather forensic data. Traditionally, containment, eradication, and recovery would follow. However, in certain situations, you might decide to learn more about the attack by observing the attacker(s). If your organization decides to monitor an incident in order to gather additional information, that decision should be made at the highest level. Ideally, written authorization should be obtained from a C-level executive and legal counsel. To begin containment, stabilize the environment; make sure it doesn’t get any worse. Ensure the attacker’s connectivity to the system(s) has been severed, and ensure that the incident cannot spread within your environment. Physical disconnection is no longer the ideal method of containment. Virtual containment is the preferred method. Begin by backing up the firewall and switch configurations, and creating checksums for both. Store the backups and checksums in a secure location. Then block all connections to the server in the firewall, and quarantine the systems in question using VLANs. Once the incident has been handled, you can restore the switch and firewall configurations from the backups.
Once you’ve contained the problem, fix the problem. It takes time. Do not restore the configuration that was compromised. It’s better to be down a bit longer than it is to restore an insecure configuration and be compromised again. Figure out how they got in, fix the problem, improve security, validate security, recover data, and then bring systems back online.
Do not restore compromised code / data. Monitor the system to ensure it’s not re-compromised.
Compile an executive level report. It should be accurate and concise. It will be submitted as evidence if the case goes to trial. Review lessons learned to improve the process for future incidents.
Do not fail to prevent re-infection. Fix the problem. Secure the environment. Assume the case will go to trial. Preserve evidence. Keep detailed notes; it might take years to resolve a case in the courts. Work closely with legal counsel.
If you’re performing contract work, do so as a subcontractor of a law firm. This should maintain confidentiality through client-attorney privilege. Likewise, if you’re planning to contract with an incident response team, do so via a law firm.
Document from where evidence was gathered, whom has access to evidence, and in what location evidence was stored. Store the evidence in a secure location.
One of the best ways to ensure the integrity of evidence is to create checksums using cryptographic hash functions. At this time, it is best to create checksums using both MD5 and SHA-1. MD5 is currently accepted, but has weaknesses. SHA-1 is not currently as widely accepted as MD5, but it should be used as a backup.
Information Warfare
Most advanced persistent threat (APT) attacks use spear-phishing.
Recognize that you might be targeted. What information might an adversary target? Focus your energy there.
Most harm is caused by insiders, and most harm caused by insiders is accidental in nature.
The offense is attempting to make your information less valuable to you or more valuable to them.
Offense is easier than defense. The offense only has to find one vulnerability. The defense has to find all of the vulnerabilities. Reduce the attack surface!
Web Communications and Security
HTTP is a stateless protocol.
Web servers should not return version information in HTTP responses.
User input validation should be performed on the client side as well as on the server side. If client-side and server-side input validation are in place, any validation issues caught on the server-side should be considered an incident.
Transport Layer Security (TLS)
Application Security Procurement Language
Get involved in the procurement process as early as possible. Software should be reviewed prior to purchase, and potential associated risks should be brought to the attention of management. Version control and configuration management should be used when deploying internally-developed applications. Developers should never touch production code.
Top 10 Secure Coding Practices
Detailed error messages can benefit attackers. For example, "Failed Login" is better than "Unknown Username" or "Incorrect Password".
Remove sample scripts and default pages from web servers.
Firefox Extensions:
Cookbook Tools - Defense in Depth
DumpSec - security auditing program for Microsoft Windows NT/XP/200x (Not very useful; PowerShell scripts could easily provide the same information)
Internet Security Technologies
Attack Strategies and Mitigation
A Whois search is typically the first step in the scanning phase of an attack or penetration test. A Whois search will provide you with a domain name’s expiration date, contact information that could be used for social engineering attacks, and the list of authoritative name servers for the domain.
When registering domain names, opt for domain privacy.
nslookup is then used to connect to the authoritative name server(s) for the domain. Once connected, a zone transfer should be attempted. The majority of the time a zone transfer will fail. nslookup can then be used to obtain the IP address(es) associated with common or known fully qualified domain names (e.g. example.org or www.example.org). ARIN is then used to obtain additional information about the network(s) associated with the IP address(es).
Don't make your organization an easy target. Limit the information that is disseminated publicly.
Patch your systems.
Reduce your attack surface.
Scan your network/systems for vulnerabilities. QualysGuard is a good cloud-based option that offers excellent reporting.
Firewalls and Honeypots
Firewalls act as the primary preventative measure in an organization. A hardened honeypot can help you determine the effectiveness of your firewalls' rules.
All connections into and out of an organization (Internet connections, VPN connections, modem connections, etc.) should pass through a firewall. Any connection that crosses a trust boundary should pass through a firewall. Firewalls must be configured properly in order to be effective. Create a firewall requirements document, and configure your firewalls based on the requirements. Test your firewall rules; ensure the traffic that should be blocked is, in fact, being blocked. Monitor the number of packets being dropped by your firewall. Create daily, weekly, and monthly reports based on this information. These reports can assist you in detecting malicious activity. The number of dropped packets should be fairly consistent. An increase in the number of dropped packets could indicate an attempted attack in progress.
Ensure that your firewall(s) are appropriately sized to handle the expected utilization.
A firewall will help protect a secure system, but if your system is vulnerable, a firewall will not be able to protect it.
Default deny, default deny, default deny!
You should be performing egress (outbound) filtering as well as ingress (inbound) filtering. If you're performing egress filtering, you can more easily detect compromised systems. Outbound filters dropping packets is indicative of a compromise (or you've blocked traffic that should be allowed).
Honeypots have no business purpose, and are only used to gain insight. Because there is no business purpose, there should be no legitimate connection attempts. Everything that hits a honeypot should be considered attack traffic. There are two types of honeypots:
- Research honeypots - systems with known vulnerabilities; used to draw in adversaries; gives us an understanding of how adversaries operate; not needed today
- Production honeypots - hardened systems; believed to be secure; gives us an understanding of how our current security posture is ineffective.
Improperly deployed honeypots can adversely affect your security posture. Research honeypots should not be deployed on production networks. Honeypots can be liabilities. If a research honeypot is compromised, and used as an attack platform, you could be found negligent. For various reasons, honeypots should not be referred to as such. It's best to refer to a honeypot as a backup DNS server.
A production honeypot should be deployed on your DMZ. Honeytokens, files that act as enticing traps for insider threats, should be created on file servers. Honeytokens should have names that are not over-the-top. Honeypots and honeytokens should look and act legitimate.
Honeypots are a nice-to-have. Focus on mitigating existing threats before deploying a honeypot.
Vulnerability Scanning
If you don't know what you have, you can't protect it. Where does your critical intellectual property and information reside? Which business processes support your critical assets? Create a single-page document with three columns: Critical Assets & Supporting Business Processes, High-probability Threats, and Vulnerabilities with Greatest Potential Impact. All major stakeholders (IT, audit, management, security, legal, finance) should agree on the contents of this document.
Communicate the value and benefits of investing in security to management on a regular basis (quarterly or monthly). Simple reports/charts that present the number of attacks against the organization work best. The number of packets dropped by your firewall is an excellent metric that you can track, chart, and report. The number of files quarantined by your antivirus solution is another excellent metric. The cost of previous incidents is also useful when the need to justify security expenditures arises.
Don’t focus on individual threats; focus on threat categories. Remediate vulnerabilities based on risk. Internal threats typically pose a greater risk than external threats. Security spending and resource allocation should reflect the risk associated with the threat vectors faced by the organization.
Firewalls can be bypassed. Firewalls alone will not adequately protect your organization.
Social engineering is very difficult to defend against. Awareness is important, but defending against social engineering attacks at the time of actual exploitation is paramount: block executables, Office macros, and embedded HTML content in email. Additional social engineering awareness training should be provided to individuals in positions which are deemed particularly vulnerable to social engineering attacks (e.g. receptionists and secretaries).
Appropriately secure modem connections.
Network Mapping Tools:
hping - Utilizes TCP as opposed to ICMP
X probe - more reliable and less intrusive than Nmap for OS fingerprinting
Vulnerability Scanners:
Prior to performing a vulnerability scan, reboot the system(s) to be scanned in order to ensure the system(s) is/are in a healthy state. Port scans and vulnerability scans have been known to crash targeted systems.
Limit wireless signal strength where possible. Always implement strong wireless encryption.
Intrusion Detection Technologies
Many organizations misunderstand and misuse intrusion detection systems (IDS). Intrusion detection systems detect attacks in progress. Timely detection and timely response are both critical. Detective technologies only work if 24/7 monitoring is in place and you have the ability to respond quickly. Think of an IDS as an alarm system for your network. If your home’s alarm system didn’t alert the police in a timely manner or the police took too long to respond to the alert, the system wouldn’t be very effective. For most organizations it’s much more cost-effective to outsource IDS monitoring. If you can’t afford 24/7 monitoring or quick response capabilities, don’t implement an IDS.
An IDS is not a replacement for a firewall.
Intrusion detection systems are among the most expensive systems to maintain. The annual cost to maintain an IDS can approach four times the initial purchase price of the system.
There are two types of intrusion detection systems:
- Network Intrusion Detection Systems (NIDS)
- Host-based Intrusion Detection Systems (HIDS)
Intrusion detection systems can be configured more aggressively than a firewall. There are four types of alerts that an IDS can generate:
- True Positive - Alerts when it should alert
- True Negative - Doesn’t alert when it shouldn’t alert
- False Positive - Alerts when it shouldn't alert
- False Negative - Doesn’t alert when it should alert
Reducing false positives results in an increase of false negatives. Reducing false negatives results in an increase of false positives. The configuration of preventative measures such as firewalls should result in zero false positives; no legitimate traffic should be blocked. Such a configuration will result in a high number of false negatives; illegitimate traffic will make it through. The configuration of intrusion detection systems should result in a number of false positives. This will allow an IDS to catch attacks that a firewall missed because the configuration of the IDS results in a lower number of false negatives. The lower the number of false negatives, the more effective the IDS and the higher the number of false positives. Most organizations should configure their NIDS such that 15% to 18% of the alerts are false positives. Particularly sensitive organizations should shoot for a 30% to 35% false positive rate. Some highly specialized organizations aim for a 55% to 60% false positive rate. If IDS monitoring is outsourced, ensure that a reasonable minimum false positive rate is stated in the contract (15% to 18%).
Convert your firewall rules to signatures in your NIDS. If alerts are received for those signatures, your firewall may be compromised.
Connect your NIDS to your network in such a way to ensure that as much traffic as possible is examined. The best link to inspect is your organization’s connection to the Internet inside the firewall. This will ensure that traffic in and out of your organization is examined. However, you will not be able to inspect all internal traffic. HIDS can be used to protect against internal threats.
Quality trumps quantity when it comes to IDS signatures.
Always consider the total cost of ownership (TCO) when evaluating any purchase. Budgets should also reflect total costs of ownership.
NIDS:
Host-based intrusion detection systems typically have very low false positive rates.
NIDS and HIPS is an ideal mix.
Intrusion Prevention Systems (IPS)
Originally functioned similar to an IDS except that it blocked signatures with false positive rates of zero instead of simply alerting. An IPS does not act as a replacement for a firewall or an IDS; it's complementary. Intrusion prevention systems (IPS) do not make intrusion detection systems (IDS) obsolete. Intrusion detection systems are detective; intrusion prevention systems are preventative. Detective systems can always be more aggressive. Preventative systems must operate with a false positive rate of zero.
Because host-based intrusion prevention systems (HIPS) reside on the host, they are capable of making intelligent decisions regarding anomalous activities. They also act as a last line of defense against both external and internal threats.
A HIPS should be installed on any computer that may connect to an untrusted network.
A network intrusion prevention system (NIPS) is an in-line device through which packets pass, as opposed to a NIDS, which receives duplicates of packets from a monitoring port on a switch. Because they operate in-line, NIPS can become a network bottleneck, and are typically more expensive than NIDS. Therefore, only purchase a NIPS if you intend to use its preventative capabilities.
All new signatures should first be configured on the NIDS, and left in production for a week. If no false positive alerts are raised after one week (or longer), then the signature should be configured on the NIPS in alerting mode. After another week (or longer) the signature should be configured on the NIPS in blocking mode. If any signature in blocking mode ever blocks production traffic (a false positive), immediately place that signature in alerting mode, and attempt to resolve the issue. If the issue cannot be resolved, the signature should be removed from the NIPS, and configured on the NIDS.
NIPS are very expensive, and may not be the most cost-effective solution to deploy on a given network.
IT Risk Management
Remember, before you spend a dollar of your budget or an hour of your time in the name of security, answer three questions:
- What is the risk?
- Is it the highest priority risk?
- Is it the most cost effective way of reducing the risk?
Remember, also: Threats x Vulnerabilities = Risk
Risk Analysis Matrix
- Impact on the x-axis
- Likelihood on the y-axis
- A scale of 1-5 on each axis works better than high, medium, and low; or 1-10
- High-likelihood, high-impact items should be an area of major concern
- Re-analyze each risk on a regular basis (every quarter)
- Areas of major concern shift depending upon the industry of the organization
- Goal is to reduce both the likelihood and impact as much as possible
You cannot control threats. However, you should focus on the threats that typically cause more damage. For many organizations, internal threats typically cause more damage. Which vulnerabilities allow the threats that your organization faces to manifest themselves? The systems you have in place or are planning to purchase should address the aforementioned vulnerabilities. Threats and vulnerabilities (and impact and likelihood) should drive security-related budgeting/purchasing decisions.
With risk comes uncertainty. We don’t know what’s going to happen. If something is guaranteed to happen, it’s not a matter of risk. Historical data is very helpful in determining the threats faced by an organization. It’s also helpful to determine the threats faced by other organizations in your industry.
The single loss expectancy (SLE) is the starting point for calculating risk. If an event occurs once, what will it cost the organization? The SLE is calculated by multiplying an assets value by the exposure factor (the percentage of the asset lost in an event). Multiplying the SLE by the number of times the event is expected to occur in a year gives us the annualized loss expectancy (ALE).
Only use quantitative analysis on the top risks determined via qualitative analysis.
Never ask management for money to purchase a specific solution. By doing so, you’re implying that the solution will solve all of the organization’s problems. Present the top eight to ten risks faced by the organization, the likelihoods of occurrence, the costs associated with incidents, and the costs associated with reducing the likelihoods of occurrence to an acceptable level along with a recommendation to only address the top three risks. By doing so, you’re making it clear that you’re not going to fix everything, you’ll be back to ask for more money later, and that addressing security issues is an ongoing process.
Risk Analysis Process:
- Threat assessment and analysis
- Asset identification and valuation
- Vulnerability analysis
- Risk evaluation
- Interim report
- Establish risk acceptance criteria
- Countermeasure selection with risk mitigation analysis
- Cost benefit analysis
- Final Report
- Repeat
Be careful if management starts throwing money at you because there are expectations attached. If you can’t meet the expectations, it’s better to focus on what you can do, than to take on too much.
Cookbook Tools - Internet Security Technologies
hping can also be used to test firewall rules.
Secure Communications
Encryption 101
Many organizations do not implement cryptography properly.
Protect your organization’s keys!
Protect your personal keys!
Do not store the key alongside the data it’s protecting.
Where are the keys?
Who has access to the keys?
How are the keys protected?
Cryptography without proper key management is ineffective.
Proprietary cryptographic algorithms should not be trusted. Publicly available cryptographic algorithms can be tested and validated. New algorithms also should not be trusted. Proper testing and validation takes years.
Implement an isolated key management server that can only be accessed via a proxy server.
Symmetric-key cryptography ensures confidentiality.
Asymmetric cryptography (a.k.a. public-key cryptography) ensures authentication.
Cryptographic hash functions ensure integrity.
Asymmetric cryptography combined with cryptographic hash functions ensure non-repudiation (authentication + integrity).
Symmetric-key algorithms use one key; requires a secure channel for key exchange.
Asymmetric-key algorithms use two keys (public and private).
Cryptographic hash functions do not use keys.
Diffie–Hellman Key Exchange (D–H) (Video)
Encryption 102
Symmetric-Key Algorithms:
Data Encryption Standard (DES) is no longer considered to be secure due to its key size being too small.
Triple DES replaced DES; meant to be a short-term solution.
Advanced Encryption Standard (AES) (Rijndael)
Asymmetric-Key Algorithms:
RSA is still considered secure, and is widely used.
ElGamal is used in GNU Privacy Guard (GPG)
Elliptic Curve Cryptography is currently used in mobile devices. Some implementation schemes and techniques are patent-encumbered as of 2013.
Symmetric-key algorithms are faster than asymmetric-key algorithms, but given their different use cases, this is irrelevant. Asymmetric-key algorithms require a larger key than symmetric-key algorithms in order to provide the same level of security.
Cryptographic Hash Functions:
MD5 produces a 128 bit hash value, and is flawed. However, it's still widely used.
SHA-1 produces a 160 bit hash value, and is considered to be secure as of 2013.
Cryptographic Attacks:
Known-plaintext attack
Chosen-plaintext attack
Chosen-ciphertext attack
Adaptive chosen-ciphertext attack
Cryptography provides confidentiality but not secrecy. Steganography provides secrecy but not confidentiality. Combining the two offers the best of both worlds.
Applying Cryptography
You must protect your data in transit, protect your data at rest, and manage and control your keys.
Real-time, time sensitive, and/or mission critical solutions require dedicated lines; VPNs are not sufficient because the Internet is chaotic.
IPsec Encapsulating Security Payload (ESP) provides limited data integrity, robust confidentiality, and limited authentication of origin.
IPsec Authentication Header (AH) provides robust data integrity and robust authentication of origin. It does not provide confidentiality.
If you have an application that does not play well with firewalls, set up an AH tunnel between your endpoints, and only allow IP protocol 51 through the firewall. Do not use AH tunnels on untrusted networks.
Effective full-disk encryption relies on strong user credentials and adherence to best practices (e.g, locking your workstation when you're not at your desk).
Certificate Revocation List (CRL)
Wireless Network Security
Enable Bluetooth functionality only when necessary. Ensure Bluetooth devices are not discoverable unless actively pairing.
ZigBee is relatively secure, but security features negatively impact battery life. Implement the minimum amount of security required in each use case.
Extensible Authentication Protocol (EAP)
WEP is insecure.
WPA2 is recommended as of 2013.
Locate WAPs with unidirectional antennas on exterior walls facing inward.
Voice Over IP
Ensure users can access emergency services as expected; communicate all emergency services-related system limitations to users.
Soft phones are more secure than hardware VoIP phones because soft phones benefit from all of the security features and functionality provided by the host computer. Soft phones are easier to use over a VPN connection, and are less expensive to deploy than hardware VoIP phones.
Segregate VoIP traffic using VLANs where possible.
Operations Security (OPSEC)
Security is a continuous process; it's a journey, not a destination.
If the current level of risk is greater than the acceptable level of risk, you have three options:
- Mitigate the risk
- Transfer the risk to a third party (insurance is a form of risk transfer)
- Minimize the potential impact (disaster recovery and incident response)
Risk needs to be reassessed on a regular basis (quarterly at minimum).
Someone should be looking at the big picture.
Read The Art of War.
Do you know who is targeting your organization? Do you know where your organization's weaknesses lie?
People are the weakest link.
Perform a detailed background check prior to hiring a new employee. If possible, contract a potential employee for a day or two (or more) in order to better evaluate how well the potential employee fits into the existing team.
Remove the expectation of privacy. Document and communicate all potential employee monitoring. In addition, notify users via login banners.
Mandatory vacation periods are useful for detecting fraud.
Employment agreements, while not always legally binding, should be in place.
- Non-competition - blanket non-competition agreements typically aren't binding unless you're given excessive compensation in return for signing the agreement. Do not sign a non-competition agreement on the same day you receive a bonus.
- Non-solicitation - useful for preventing customers from hiring consultants away from a consulting firm after the customer's contract ends.
- Non-disclosure (NDA) - most critical
Always consult an attorney prior to signing any employment agreement.
A data classification system must be in place. Otherwise, an NDA is useless. Data should be classified or private by default.
Reduce the amount of organizational information that is publicly available.
Resources for reconnaissance:
Know your organization. Talk to your employees.
Windows Security
The Windows Security Infrastructure
All software contains vulnerabilities.
Windows servers running in a DMZ should not be domain-joined (i.e. use a workgroup).
You should always implement redundant domain controllers.
NTLM should not be used. If NTLMv2 is still required (i.e. if you're running clients or servers prior to Windows 7 and Windows Server 2008 R2), segregate the legacy machines in a separate domain, and configure a one-way trust between the legacy domain and your existing domain, which should only support Kerberos.
Service Packs, Hotfixes, and Backups
Disable and/or uninstall unnecessary services.
Windows Access Controls
NTFS uses discretionary access control. An implicit deny exists in every ACL. If a conflict exists, explicit denies always override explicit allows.
Permissions should be applied using the following model:
Accounts --> Global Groups --> Universal Groups --> Local Groups --> Permissions and Rights
Global groups represent roles. Universal groups are optional.
Set permissions for shared folders using NTFS. Share permissions should always be set to Full Control for Authenticated Users.
Block traffic from the Internet destined for the following ports:
TCP 135 (RPC Endpoint Mapper)
UDP 137 (NetLogon, NetBT Name Services)
UDP 138 (DFSN, NetLogon, NetBT Datagram Services)
TCP 139 (DFSN, NetLogon, NetBT Session Services)
TCP/UDP 445 (SMB,CIFS,SMB2, DFSN, LSARPC, NbtSS, NetLogonR, SamR, SrvSvc)
No one should have both full administrative rights on a server as well as the ability to modify log files. IT should have full administrative rights; security should administer the log files.
Individuals with the backup/restore files and directories right can circumvent NTFS permissions. Reserve the restore right for highly trusted administrators only.
Enforcing Security Policy
Microsoft Security Compliance Manager (SCM)
If you have console access to your servers, do not allow the local Administrator account to login through remote desktop services or access the computer from the network.
Do not rename the local Administrator account. Security through obscurity is ineffective.
Administrators should have two accounts: one normal account and one administrator account. Accounts should never be shared. Administrators should never log into their workstation with their administrator account.
Securing Windows Network Services
The best way to secure a service is to uninstall the service. If you don’t need a service, get rid of it.
You should patch all installed software even if it’s disabled.
Uninstall (or, at least, disable) unnecessary items in a local area connections properties dialog box.
Disable NetBIOS over TCP/IP, if possible. It’s almost always possible to disable NetBIOS.
SolarWinds offers a log forwarder for Windows that is capable of forwarding Windows event logs to a syslog server. The log forwarder is provided with the Kiwi Syslog Server, the SolarWinds Log & Event Manager, as well as other SolarWinds products.
If you plan to run IIS in a DMZ, implement IIS on top of a Windows Server Core installation.
Do not host web content from a Windows boot volume; a separate NTFS volume should be used.
General Best Practices for Securing Services
Is it required? If not, disable it.
Is there a more secure alternative?
Install the latest version, and ensure it’s fully patched.
Remove or disable any unnecessary components.
Use multi-factor authentication if possible.
Use strong passphrases.
Authenticate devices at the network level.
If encryption is baked-in, use it. If not, use TLS or IPsec.
Microsoft Security Assessment Tool
Automation, Auditing, and Forensics
Windows Management Instrumentation (WMI)
Implement change management to ensure compliance. All changes should be processed via the change management system.
Microsoft Baseline Security Analyzer
As far as logging is concerned, you can never over do it. At minimum, you should log the following:
- Administrator access and changes to administrator access rights
- Critical data access
- Network entry points (web servers, email servers, DMZ servers)
Do not store critical data itself within your logs (i.e. do not store social security numbers or credit card numbers within your log files).
Snapshot certain aspects of each server’s configuration on a regular basis, and write the information to a text file. At minimum, the following information should be tracked:
- User accounts
- Administrators group membership
- Running processes
- Listening ports
Linux Security
Securing Linux/Unix - Structure and Commands
Securing Linux/Unix - Permissions and User Account
sudo find /etc -mtime -1 -print - Prints all files that have been modified within the past day (24 hours).
Never log in as root. Log in as a normal user, and use su or sudo.
man 5 login.defs
man chage
Securing Linux/Unix - Boot Process, Run Levels, and Services
Ensure your /etc/crontab files and the scripts they call do not contain malicious entries. Tripwire can be used to monitor these files.
man 5 inittab
man service
man chkconfig
If a service is not required, it should be disabled, and then uninstalled. Disabled services should still be patched.
NFS should really be used in combination with ldap in order to provide consistent UID/GID mapping for all users. Otherwise, UIDs/GIDs need to be consistent on all of the hosts involved.
Always disable NetBIOS support in Samba.
Always perform a full port scan against a system prior to deploying it in a production environment.
Be sure to secure all printers and copiers in your organization. Many printers and copiers have built-in web servers and/or other remote management interfaces.
A local SMTP server is not required to send mail. The number of SMTP servers in an organization should be limited.
Simple Network Management Protocol (SNMP)
Useful Services
Securing Linux/Unix - Logs and Log Management
Use syslog as your standard logging format, and use tools like SolarWinds Log Forwarder for Windows to convert Windows logs to the syslog format. All servers should store logs locally, and forward logs to a centralized syslog server, which will in turn feed logs into your log monitoring and analysis tools (e.g. Splunk). Many organization use their log monitoring and analysis tool as their syslog server. This is not ideal. A stand-alone, centralized syslog server is better able to provide for the authenticity and integrity of the logs.
Applications with weaker security require more verbose logging.
There’s no such thing as logs that are too verbose. That being said, you need to balance log verbosity with storage requirements.
When forwarding logs to a remote server using syslog, enter the remote server's IP address, not its FQDN, in the configuration file.
rsyslog is the currently recommended implementation of syslog.
Securing Linux/Unix - Patch Management
Always reboot servers after applying updates in order to identify any potential issues with the updates.
Securing Linux/Unix - Security Enhancement Utilities
Do not add every file on a system to Tripwire’s database.
