Category: Best Practices

Brief Overview

Standards and Organization Controls (SOC) is an information security framework designed to help companies stress test their information security controls and catch any deficiencies in a company’s security posture PRIOR to a government inspection or external third party audit.

A SOC audit is an internal company audit primarily designed to provide the company management and potential external investors with assurances that the company is following industry best practices, internal polices and procedures, and is meeting obligatory government regulations. The audits are typically conducted annually .

There are two different SOC audits. SOC1 verifies information security controls are in place relating to possible financial impacts (i.e. external investors). SOC2 is to verify the security and privacy of the data itself (i.e. the customer data).

In total, there are 4 versions of a SOC audit.

• SOC1, Type 1 – verifies controls actually exist and reviews an organization processes and controls.
• SOC1, Type 2 – verifies if controls actually work and looks at if processes and procedures are actually being followed.
• SOC2, Type 1 – verifies controls actually exist and reviews an organization processes and controls.
• SOC2, Type 2 – verifies if controls actually work and looks at if processes and procedures are actually being followed.

The primary audit of interest to most users is a SOC 2. It defines requirements to manage and store customer data based these five Trust Services Criteria (TSC):

• Security – Protect information from unauthorized access.
• Availability – Ensure employees and customers can rely on the systems to work.
• Processing integrity – Verify the company systems operate as intended.
• Confidentiality – Protect confidential information by limiting its access, storage, and use.
• Privacy – Safeguard PII against unauthorized users.

In order to pass a SOC2 audit, you must meet all five Trust Services Criteria. The criteria are defined specifically in the nine (9) categories listed below.

General Criteria

• CC1 – Organization – It establishes how your organization has been incorporated and addresses how your Board of Directors was formed. It also includes HR topics such as recruitment and training practice. Does the organization value integrity and security?
• CC2 – Communication – Establish your obligation to collect information and describe how it will be disseminated internally and externally. Are policies and procedures in place to ensure security?
• CC3 – Risk – Financial risks, but many modern technology companies pivot implementation of these controls towards technical risk. Does the organization analyze risk and monitor changes?
• CC4 – Monitoring – How you intend to monitor your adherence to the controls themselves. They establish the cadence for your audit and how you intend to communicate the results to internal and external stakeholders. Does the organization monitor, evaluate, and communicate the effectiveness of its controls?
• CC5 – Control Activities – Take place within the technology environment you’ve deployed, as well as within the policies and procedures you’ve adopted. The most important element of the CC5 controls is the establishment of the policies themselves and how these are distributed to personnel. Are the proper controls, processes, and technologies in place to reduce risk?

Specific Criteria

• CC6 – Logical & Physical Access – The biggest section of controls. Everything you have to say about access, data handling and disposal, and threat prevention is included somewhere in the CC6 series. Does the organization encrypt data? Does it control who can access data and restrict physical access to servers?
• CC7 – Operations – The pillars of your security architecture. Specifies certain tool choices such as those regarding vulnerability detection and anomaly detection. Are systems monitored to ensure they function properly? Are incident response and disaster recovery plans in place?
• CC8 – Changes – It seeks to establish an approval hierarchy around significant elements of the control environment such as policies, procedures, or technologies. As long as your environment does not permit unilateral changes to these elements of the control environment, you should be in good shape. Are material changes to systems properly tested and approved beforehand?
• CC9 – Mitigations – To prescribe the activities and steps that should be taken to mitigate those risks. For example, if database failure were identified as a risk, a mitigation action would be taking backups of that database. Does the organization mitigate risk through proper business processes and vendor management?

Additional Criteria

Two additional criteria have been developed that may or may not be included in an audit. It depends on the type of data a company handles.

• P Series – Privacy – Focused on businesses that have substantial privacy obligations and are already equipped with solid policy. So what’s needed is to map the existing controls to the P series controls.
• PI Series – Processing Integrity – Situations where your organization is performing transactions on behalf of another organization. Just as with the privacy controls, it’s likely that your customer contract already contains many of the guarantees the PI controls seek to address. Your task will be to map your existing contracts, commitments, and policies back to the PI series controls.

Introduction

Users, computers, and even entire networks can be all be compromised. Depending on the scenario, security analyst’s have to look out for different type of indicator’s of compromise (IOC). I discuss multiple scenarios below and give examples of what to be on the lookout for. If a compromise is suspected, you should collect basic artifacts about the host and user affected. They will be needed as a starting point, if a forensic investigation is undertaken.

Basic artifacts to collect, when a suspected compromise

• Suspected email address. Domain of sender.
• Link or URL in an email.
• Files received by ftp, p2p, or as email attachments.
• IP address of host.
• Browser history.
• Affected user.
• Log entries for past xx hours.
• Files name, size, and hash of new files that have suddenly appeared (like in a temp folder).
• Running processes.

Examples of IOC of a User’s Account

• Suspicious Logins – Attempts by accounts that do not exist, afterhours login successes.
• Unusually user account activity. – Watch for time of day, systems accessed, type and volume of data accessed.
• Geographic irregularities – Where is a user logging in from? Does a user account login from two different countries in a short period of time?

Example of a Server or Workstation Compromise

• Unusual network traffic – Typically monitor outbound traffic for spikes to unknown locations.
• Review for log anomalies. – were any files downloaded around the suspected start time.
• Increase in database read volume – When the attacker attempts to extract the full credit card database, it will generate an enormous amount of read volume.
• Suspicious registry or file system changes – Need to create a baseline and define what a clean registry looks like. Use FIM to monitor for changes. Was new software installed?
• Bundles Of Data In The Wrong Places – Do you see large gigabytes of information and data where they should not exist, particularly in compressed in archive formats? In the temp folder? If unexplained encrypted files are discovered or random files appear in a folder location typically not monitored by FIM.

Sample Indicator’s of a Network Compromise

• Unusual DNS requests and web traffic showing non-human behavior – Is it an unknown web browser, curl command. Check for user-agent string which identifies the browser. Does a user reach out to 20 different sites simultaneously?
• Geographic irregularities – Connections to countries that the company does not do business with.
• Mismatched Port-Application Traffic – ex. DNS request over port 80.
• Signs Of DDoS Activity – Distributed denial-of-service attacks (DDoS) are frequently used as smokescreens to camouflage other more pernicious attacks. Signs of DDos are slow network performance, unavailability of websites, firewall failover, or back-end systems working at max capacity for unknown reasons. DDOS attempt to overloading mainstream services, as well as security reporting systems, such as IPS/IDS or SIEM solutions,. This presents new opportunities for cybercriminals to plant malware or steal sensitive data. As a result, any DDoS attack should also be reviewed for related data breach activity.
• Large Numbers Of Requests For The Same File – Is a single user or IP making 500 requests for ‘join.php’.
• DNS Request Anomalies – A large spike in DNS requests from a specific host, “Watching for patterns of DNS requests to external hosts, compared against geolocation IP and reputation data, and implementing appropriate filtering.

Web Browser Indicators

• HTML response sizes – If attackers use SQL injection to extract data through a Web application, the requests issued by them will usually have a larger HTML response size than a normal request. If the attacker extracts a full credit card database, then a single response for that attacker might be 50 MB, where a normal response is only 200 KB.

Mobile Device Compromises

• Mobile Device Profile Changes – changes to a mobile user’s device settings, replacement of user apps, gains a new configuration profile that was not provided by the enterprise.

References

https://www.darkreading.com/cyberattacks-data-breaches/top-15-indicators-of-compromise

Introduction

An enterprise security operations center (SOC) analyst’s responsibilities are both wide and varied. Based on my personal experience, this is a list of duties working in the industry. If you have limited time or resources, you should consider focusing on reviewing log events.

Monitor Security Systems

Security systems should be continuously monitored to look for compromised devices, prevent unauthorized access, or verify hardware configurations and patches been installed. Continuously ask yourself, how can I layer my defenses, am I collecting logs, and am I protecting systems and resources.

Consider the below security systems as a minimum for monitoring.

• Antivirus software agent on endpoints.
• Vulnerability scanning to look for missing software patches.
• Intrusion Detection / Prevention System to detect malicious traffic inside the network,
• Network devices, like routers, firewalls, VPN, Citrix should be configured for least privilege.
• On switches, segregate network using VLANS for logical access controls.
• Use a SIEM for log review and alerting.
• Employ FIM to detect critical file changes.
• Physical access controls. (cameras, key cards, other.)
• Servers to collect logs for meet compliance requirements and for forensic investigations.
• Authentication servers. Active Directory. Employ Logical access controls.
• Internal Firewalls to protect servers that store and process PII data, (i.e. credit cards).
• Web proxy to blacklist suspicious sites.
• Perimeter firewall to block connections, IDS, prevent DDOS attacks, and scan attachments.
• Network Access Controls to prevent rogue wireless devices. Also, Implement 802.1x.

Review Log Events Using a SIEM

Not all events are created equal. But, some top events to look out for in a SIEM are shown here. This list was developed from hands on experience and researching various blogs. They are not listed in any specific order and should all be treated equally.

1. Monitor for policy changes.
2. User rights assignments.
3. Local Account authentication policy changes.
4. Local user account changes.
5. Sensitive Group Changes. (PIM activations. Domain Admins, SQL admins, etc.)
6. Local group membership changes.
7. New software downloads or installs.
8. Failed login attempts or lockouts.
9. Any attempt to logon as an administrator. (domain admins, afterhours, etc)
10. Firewall policy changes. (config changes)
11. New devices attached.
12. Monitor for exfiltration of data. (use SIEM, Netflow, or NIDS systems)
13. User to User network traffic. – Should be near zero. Traffic is typically client to server.

Reference: by https://windowsultimatesecurity.com

Perform Threat Hunting

Operations centers spend the bulk of their time looking for potential threats that may affect systems or people. Threats are wide and varied, from an un-known person walking the hallways to an employee walking out of door with a USB drive. A variety of different tools will be used to hunt for all the different kinds of threats.

• Run daily File Integrity Management (FIM) scan. (Changes to registry or system files)
• Run daily malware/virus/rootkit scans on all hosts.
• Monitor wireless networks for un-authorized connections.
• Conduct daily external port scans to verify only authorized ports in the firewall are open.
• Run weekly MITRE Attack/Defense testing. (Do your defenses actually work).
• Review Conditional Access policy changes in Azure, Intune, or Purview.
• Investigate SIEM alerts. Endpoint (HIDS) events and Internal Network (NIDS) events.
• Review DNS logs for allowed/blocked access to suspicious sites.
• Review DNS logs to verify un-authorized sites was actually blocked.
• Process phish tank emails. (Block users from receiving malicious emails from senders or domains).
• Verify the endpoint AV agent is running & communicating.
• Review physical cameras for un-authorized access.
• Review external Firewall logs.

Conduct Risk Assessments

Risk assessments attempt to categorize all risks and help develop a priority improvement list. Risk can come from fines by government agencies, external attackers, internal employee threats, and other sources. Typical questions that are asked are, what is likely to occur? What actions can be taken to prevent it? and how easily can fixes be implemented? Risk assessments are often required by insurance brokers, prior to issuing a policy.

• Run weekly vulnerability scans. (patching, obsolete software, or expired SSL certs).
• Verify the scanner has recently updated rule set.
• Ensure logs are collected and stored. (90 days hot + 12 months cold)
• Backup all logs nightly and run file hash to prevent unauthorized modifications.
• Dispose of logs older then the data loss prevention or retention policy.
• Conduct clean desk inspections.
• Annually conduct a Pen test against all external facing websites.
• Sending out simulated phishing emails to all employees.

Conduct Compliance Audits

Look for weaknesses in the polices or procedures that you IT staff use. How can you make security better.

• Conduct SOC2 internal audits.
• Prepare due diligence reports for outside auditors.
• Monitor Third Party venders for data breach disclosures.
• Run hardening scans. (Do the assets meet company policy; MS or CIS benchmarks).
• Maintain an inventory of all assets.
• Develop company internet filtering standards for users.
• Review network device config files for changes w/o authorization.
• Verify encryption is used for all hard drives.
• Implement DLP Policies. (unauthorized printing of data, SSN, CC numbers, etc.).
• Review your Microsoft Azure secure score.
• Run PCI compliance scans against external websites.
• Conduct tests against the firewall to verify it is blocking traffic from external countries or emails are blocking files with specific extensions.
• Carefully review Group Policy Objects, such as what computers can join the network, password enforcement, folder redirection (so files are not saved locally), etc.

Verify System’s Meet Hardening Standards

All servers and workstation need to meet minimum configuration hardening (aka. compliance) standards. The CIS Benchmarks are prescriptive configuration recommendations for more than 25+ vendor product families. They represent the consensus-based effort of cybersecurity experts globally to help you protect your systems against threats more confidently.

Reference: https://www.cisecurity.org/cis-benchmarks

Collect Logs From Critical Sources

Log collection is required by government regulations and industry standards. You will need to collect logs from a variety of critical systems. Logs typically need to be kept for 12 months. Be sure to back them up offsite for disaster recovery reasons.

The types of logs a SOC operations center should collect are:

• Application Logging
  • User account management
  • Access control events
  • Configuration changes
• Servers & Workstation Logging
  • Operating system logs.
    • System event logs. (shut down or restart service, etc.)
    • Audit logs. (Privileged account activity, files accessed, authentication attempts, etc.)
• Other Potentially Logging systems
  • Network Segmentation controls (switches)
  • Remote access software (VPN) or Citrix Gateway (NetScaler)
  • Virtual Hosts Servers like VMWare (ESX)
  • SQL data base access – Who access the databases.
  • DNS Proxy Servers.
  • FTP Servers – who logged in and what files were downloaded.
  • Linux servers, auth (login attempts) & sudo elevation.