A Short brief about Advanced Persistence Threat

Advanced Persistence Threat, these groups are not an individual identity. They are mostly organizations or countries (based on agenda/political reasons) with expertise teams. Not a normal expert, they are trained professionals and they have the potential to break in any systems and move laterally in a LAN without being caught for years.

Even your antivirus cannot detect this movement, because they do not create malwares, they just abuse genuine applications (like PowerShell) and move laterally like a genuine process.

Key components of an APT is, moving laterally, being persistence, create CnC channel, getting payload with just a DNS request and more. Every APT attacks so far recorded, they do have uniqueways of propagating a network and they rely highly on open ports, unprotected network zones, vulnearables applications, network shares,etc. Once they break in, they do whatever they intend to do.

Read More

Types of SOC

 Categorize SOCs that are internal to the constituency into five organizational models of how the team is comprised,

1. Security team.

No standing incident detection or response capability exists. In the event of a computer security incident, resources are gathered (usually from within the constituency) to deal with the problem, reconstitute systems, and then 16 stands down.

Results can vary widely as there is no central watch or consistent pool of expertise, and processes for incident handling are usually poorly defined. Constituencies composed of fewer than 1,000 users or IPs usually fall into this category.

2. Internal distributed SOC.

A standing SOC exists but is primarily composed of individuals whose organizational position is outside the SOC and whose primary job is IT or security related but not necessarily CND related.

One person or a small group is responsible for coordinating security operations, but the heavy lifting is carried out by individuals who are matrixed in from other organizations. SOCs supporting a small- to medium-sized constituency, perhaps 500 to 5,000 users or IPs, often fall into this category.

3. Internal centralized SOC.

A dedicated team of IT and cybersecurity professionals comprise a standing CND capability, providing ongoing services.

The resources and the authorities necessary to sustain the day-to-day network defense mission exist in a formally recognized entity, usually with its own budget. This team reports to a SOC manager who is responsible for overseeing the CND program for the constituency. Most SOCs fall into this category, typically serving constituencies ranging from 5,000 to 100,000 users or IP addresses.

4. Internal combined distributed and centralized SOC.

The Security Operations Center is composed of both a central team (as with internal centralized SOCs) and resources from elsewhere in the constituency (as with internal distributed SOCs). Individuals supporting CND operations outside of the main SOC are not recognized as a separate and distinct SOC entity.

For larger constituencies, this model strikes a balance between having a coherent, synchronized team and maintaining an understanding of edge IT assets and enclaves. SOCs with constituencies in the 25,000–500,000 user/IP range may pursue this approach, especially if their constituency is geographically distributed or they serve a highly heterogeneous computing environment.

5. Coordinating SOC.

The SOC mediates and facilitates CND activities between multiple subordinate distinct SOCs, typically for a large constituency, perhaps measured in the millions of users or IP addresses.

A coordinating SOC usually provides consulting services to a constituency that can be quite diverse.

It typically does not have active or comprehensive visibility down to the end host and most often has limited authority over its constituency.

Coordinating SOCs often serve as distribution hubs for cyber intel, best practices, and training. They also can offer analysis and forensics services, when requested by subordinate SOCs.

Read More

A short brief about Security Operations Center

 

What Is a Security Operations Center (SOC) ?

A SOC is a team primarily composed of security analysts organized to detect, analyze, respond to, report on, and prevent cybersecurity incidents.

The practice of defense against unauthorized activity within computer networks, including monitoring, detection, analysis (such as trend and pattern analysis), and response and restoration activities.

There are many terms that have been used to reference a team of cybersecurity experts assembled to perform CND.

They include: ‚

• Computer Security Incident Response Team (CSIRT) ‚
• Computer Incident Response Team (CIRT) ‚
• Computer Incident Response Center (or Capability) (CIRC) ‚
• Computer Security Incident Response Center (or Capability) (CSIRC) ‚
• Security Operations Center (SOC) ‚
• Cybersecurity Operations Center (CSOC)
• ‚ Computer Emergency Response Team(CERT)

In order for an organization to be considered a SOC, it must:

• 1. Provide a means for constituents to report suspected cybersecurity incidents
• 2. Provide incident handling assistance to constituents
• 3. Disseminate incident-related information to constituents and external parties.

Read More

Types of logs in windows ?

 In specific with windows logs are three type system, security, and application

Application log

Each application will have their logs, which will be triggered when it contains errors or warning will be sent to SOC for review.

Security log

Suspicious User activities for account success and failure logins will be logged and process creation, termination for each and every file accessed by user account logged will be logged into this category.

System log

Logs which footprinting the process of kernel boot, driver updates or failure, windows update and more interesting things will be logged into system log category.

Since security is our concern, we will discuss security logs, look below the figure for better understanding, In this screenshot analyst is analyzing a log for windows event sources.

As I told earlier Siem is built for visibility so, whatever security issues happening with end users should be triggered to Security operation center.

In the above picture, an analyst has clear visibility of end user activities.In this, we can see the event id is 4720.

When a new user account is created for domain accounts or local SAM accounts.Event logs will be established with event id 4720 with respect to new user account creation.

Read More

SIEM Better Visibility for SOC Analyst

 We are in the complex world where attacks are increasing day by day, so today the cyber intelligence depends on SIEM as a part of infosec (security incident and event management).

Most companies depend on logs and packets to have a better view.. above 90 % of them are working with logs rather than packets. People, process, and technology will be a triangle for security operations.

      

                                   Security Triangle  

  

  From this post, you will be knowing that what are logs and how they are parsed through SIEM for better visibility for an analyst to handle an incident.

Logs are an essential part of each device. logs are meaningful elements which can show relevant information about end-user activities to security analyst under SOC(Security Operation Center) and it is also part of the review for audit and compliance.

Let’s take the scenario that the Windows operating system may be your event source and Analyst at another end. What are the activities you are performing from power on to power off will be logged and logs will be sent to Security Operation Center. Users unusual activities will be recorded as an incident in Security operation center.

Logs are three types which will be triggered according to your activities performed in your system

Read More

Top 10 Use Cases for SIEM

 With the growing use of SIEM solutions, business houses are keen on solving a number security and business use cases seen during their day-to-day operations. In this post, we will go through the top 10 use cases with an overview of how you can use  to detect any such behavior in your infrastructure

The following are the top 10 use cases:

1. Authentication Activities

Abnormal authentication attempts, off hour authentication attempts etc, using data from Windows, Unix and any other authentication application.

2. Shared Accounts

Multiple sources(internal/external) making session requests for a particular user account during a given time frame, using login data from sources like Windows, Unix etc.

3. Session Activities

Session duration, inactive sessions etc, using login session related data specifically from Windows server.

4. Connections Details

Connections can be genuine or bogus. Suspicious behavior may include connection attempts on closed ports, blocked internal connections, connection made to bad destinations etc, using data from firewalls, network devices or flow data. External sources can further be enriched to discover the domain name, country and geographical details.

5. Abnormal Administrative Behavior

Monitoring inactive accounts, accounts with unchanged passwords, abnormal account management activities etc, using data from AD account management related activities.

6. Information Theft

Data exfiltration attempts, information leakage through emails etc, using data from mail servers, file sharing applications etc.

7. Vulnerability Scanning and Correlation

Identification and correlation of security vulnerabilities detected by applications like Qualys against other suspicious events.

8. Statistical Analysis

Statistical analysis can be done to study the nature of data. Functions like average, median, quantile, quartile etc can be used for the purpose. Numerical data from all kind of sources can be used to monitor relations like ratio of inbound to outbound bandwidth usage, data usage per application, response time comparison etc.

9. Intrusion Detection and Infections

This can be done by using data from IDS/IPS, antivirus, anti-malware applications etc.

10. System Change Activities

This can be done by using data for changes in configurations, audit configuration changes, policy changes, policy violations, etc.

Readers, you can share your own use cases which you have experienced in the comment section below.

Read More

Critical Controls and SIEM

 Critical Control 1: Inventory of Authorized and Unauthorized Devices

SIEM can correlate user activity with user rights and roles to detect violations of least
privilege enforcement, which is required by this control.

Critical Control 2: Inventory of Authorized and Unauthorized Software

SIEM should be used as the inventory database of authorized software
products for correlation with network and application activity.

Critical Control 3: Secure Conjurations for Hardware and Software on Laptops, Workstations, and Servers

Known vulnerabilities are still a leading avenue for successful exploits. If an automated
device scanning tool discovers a mis configured network system during a Common
Configuration Enumeration (CCE) scan, that misconfiguration should be reported to the
SIEM as a central source for these alerts. This helps with troubleshooting incidents as
well as improving overall security posture.

Critical Control 4: Secure Configurations for Network Devices such as Firewalls, Routers,and Switches

Any misconfiguration on network devices should also be reported to the SIEM for consolidated analysis

Critical Control 5: Boundary Defense

Network rule violations, like CCE discoveries, should also be reported to one central
source (a SIEM) for correlation with authorized inventory data stored in the SIEM
solution

Critical Control 6: Maintenance, Monitoring, and Analysis of Audit Logs

Control 6 is basically a control about SIEMs, which are a leading means for collecting
and centralizing critical log data; in fact, there is even a subcontrol for analysis that
studies SIEM specifically. SIEMs are the core analysis engine that can analyze log events
as they occur.

Critical Control 7: Application Software Security

Like CCE scan results, vulnerabilities that are discovered in software applications should
also be reported to a central source where these vulnerabilities can be correlated with
other events concerning a particular system. SIEMs are a good place to store these scan
results and correlate the information with network data, captured through logs, to
determine whether vulnerabilities are being exploited in real time.

Critical Control 8: Controlled Use of Administrative Privileges

When the principles of this control are not met (such as an administrator running a
web browser or unnecessary use of administrator accounts), SIEM can correlate access
logs to detect the violation and generate an alert.

Critical Control 9: Controlled Access Based on Need to Know

SIEM can correlate user activity with user rights and roles to detect violations of least
privilege enforcement, which is required by this control.

Critical Control 10: Continuous Critical Control

SIEM can correlate vulnerability context with actual system activity to determine
whether vulnerabilities are being exploited.

Critical Control 11: Account Monitoring and Control

Abnormal account activity can only be detected when compared to a baseline of
known good activity. The baseline to meet this control should be recorded by the
SIEM; and, as future snapshots or baselines are recorded, they can be compared to the
approved baseline in the SIEM.

Critical Control 12: Malware Defenses

Malware that is discovered should be recorded according to this control. Centralized
anti-malware tools should report their findings to a SIEM, which correlates against
system and vulnerability data to determine which systems pose a greater risk due to the
malware discovered on that system

Critical Control 13: Limitation and Control of Network Ports, Protocols, and Services

if a system has a running port, protocol, or service that has not been authorized, it should also be reported to a central source where these vulnerabilities can be correlated with other events concerning a particular system. SIEMs can monitor log data to detect traffic over restricted ports, protocols, and services. Organizations can use these controls to decide which ports and services are useful for business, which are not, and which types of traffic and ports to limit

Critical Control 14: Wireless Device Control

Device misconfigurations and wireless intrusions should be reported to a central
database for incident handling purposes. A SIEM is a perfect candidate to consolidate
this information and use it for correlation or detection of threats to wireless
infrastructure

Critical Control 15: Data Loss Prevention

data loss rule violations, like CCE discoveries, should also be reported to one central source such as a SIEM, which can correlate data loss events with inventory or asset information as well as other system and user activity to detect complex breaches of sensitive data.

Critical Control 15: Data Loss Prevention

 

data loss rule violations, like CCE discoveries, should also be reported to one central source such as a SIEM, which can correlate data loss events with inventory or asset information as well as other system and user activity to detect complex breaches of sensitive data.

Read More

How Exactly Would the SIEM raise an alert ?

 Well, now you know that the logs from different devices are being forwarded into the SIEM. Take an example: A port scan is initiated against a specific machine. In such a case, the machine would generate a lot of unusual logs.

Analyzing the logs, it will be clear that a number of connection failures are occurring to different ports in regular intervals.

Seeing packet information if possible, we can detect the SYN requests being sent from the same IP to the same IP but to different ports in regular intervals. That concludes that somebody initiated an SYN scan against our asset.

The SIEM automates this process and raises alerts. Different solutions do this in different ways but produce same results.

The path to SIEM success looks something like this:

• Collect logs from standard security sources.
• Enrich logs with supplemental data.
• Global Threat Intelligence (Black Lists).
• Human Resource / Internet Download Management.
• Correlate — finding the proverbial needles in the log haystacks.
• Investigate — follow up and fix.
• The document — Standard Operating Procedures, Service Level Agreements, Trouble Tickets.
• Incorporate — Build white lists, new content.

Read More

Security Information/Events Logs

• Log Collection is the heart and soul of a SIEM – the more log sources that

send logs to the SIEM, the more that can be accomplished with the SIEM.

 

• Logs on their own rarely contain the information needed to understand their

contents within the context of your business.

 

• Security Analysts have limited bandwidth to be familiar with every last system

that your IT operation depends on.

 

• With only the logs, all an analyst sees is “Connection from Host A to Host B”

 

• Yet, to the administrator of that system, this becomes “Daily Activity Transfer

from Point of Sales to Accounts Receivable”.

 

• The Analyst needs this information to make a reasoned assessment of any

security alert involving this connection.

 

• The true value of logs is in correlation to getting actionable information.

 

Log Records Cover:

• • Normal activity
  • Error conditions
  • Configuration changes
  • Policy changes
  • User access to assets
  • Incident alerts
  • Unauthorized use of resources
  • Non-privileged access to files
  • User behavior patterns
  • Clearing of sensitive data
  • Access to audit trails

Logs provide feedback on the status of IT resources and all activity going through them.

How logs reach the SIEM?

Logs are fetched to the SIEM in two different ways. Agent-based & Non-Agent based. In the agent-based approach, a log pushing agent is installed in the client machine from which the logs are collected.

Then this agent is configured to forward logs into the solution. In the latter type, the client system sends logs on its own using a service like Syslog or Windows Event Collector service, etc.

There are also specific applications & devices which can be integrated through a series of vendor-specific procedures.

Read More

How does SIEM Works?

 One-stop answer is a co-relation. You may have noticed the word “Co-Relation” Yes, for the question How the SIEM works, But not that alone of course.

Basically, a SIEM tool collects logs from devices present in the Organization’s infrastructure. Some solutions also collect NetFlow and even raw packets. With the collected data(mainly logs, packets), the tool provides an insight into the happenings of the network.

It provides data for each event occurring in the network and thus acts as a complete centralized security monitoring system.

In addition to this, the SIEM tool can be configured to detect a specific incident. For example, a user is trying to log in to an AD server. For the first 3 times the authentication failed and the 4th time it succeeded. Now, this is an incident to look upon.

There are many possibilities. Maybe a person is trying to guess the password of another user and got it right, which is a breach. Or maybe if the user forgot his password but got it right at the end and so on. This is where co-relation comes in.

For such a case, a co-relation rule can be made in such a way that, If an authentication failure event is happening 3 times consecutively followed by success in a specific time period, then alert pops up.

This can be further investigated further by analyzing the logs from the respective machines. So my definition of co-relation is: “ It is the rule which aggregates events into an incident which is defined by specific application or scenario.”

Read More

Security Information and Event Management (SIEM)

 SIEM software products and services combine security information management (SIM) and security event management (SEM). They provide real-time analysis of security alerts generated by network hardware and applications.

Vendors sell SIEM as software, as appliances or as managed services; these products are also used to log security data and generate reports for compliance purposes.

Although the industry has settled on the term ‘SIEM’ as the catch-all term for

this type of security software, it evolved from several different (but complementary)

technologies that came before it.

Few other terms to know;

• LMS“Log Management System” – a system that collects and stores log files (from Operating Systems, Applications, etc) from multiple hosts and systems into a single location, allowing centralized access to logs instead of accessing them from each system individually.

 

• SLM /SEM “Security Log/Event Management” – an LMS, but marketed towards security analysts instead of system administrators. SEM is about highlighting log entries as more significant to security than others.

 

• SIM “Security Information Management” – an Asset Management system, but with features to join security information too. Hosts may have vulnerability reports listed in their summaries, Intrusion Detection and AntiVirus alerts may be shown mapped to the systems involved.

 

• SEC “Security Event Correlation” – To a particular piece of software, three failed login attempts to the same user account from three different clients, are just three lines in their logfile. To an analyst, that is a particular sequence of events worthy of investigation, and Log Correlation (looking for patterns in log files) is a way to raise alerts when these things happen.

 

• SIEM “Security Information and Event Management” – SIEM is the “All of the Above” option, and as the above technologies become merged into single products, it became the generalized term for managing information generated from security controls and infrastructure. We’ll use the term SIEM for the rest of this presentation.

• Data aggregation: Log management aggregates data from many sources, including network, security, servers, databases, applications, providing the ability to consolidate monitored data to help avoid missing crucial events.
• Correlation: looks for common attributes and links events together into meaningful bundles. This technology provides the ability to do a variety of correlation techniques to integrate different sources, to turn data into useful information. Correlation is typically a function of the Security Event Management part of a full SIEM solution
• Alerting: the automated analysis of correlated events and production of alerts, to tell recipients of immediate issues. Alerting can be to a dashboard or sent via third-party channels such as email.
• Dashboards: Tools can take event data and turn it into informational charts to aid in seeing patterns, or identifying activity that is not forming a standard pattern.
• Compliance: Applications can be employed to automate the gathering of compliance data, producing reports that adapt to existing security, governance, and auditing processes.
• Retention: employing long-term storage of historical data to facilitate the correlation of data over time, and to provide the retention necessary for compliance requirements. Long-term log data retention is critical in forensic investigations as it is unlikely that the discovery of a network breach will be at the time of the breach occurring.

• Forensic analysis: The ability to search across logs on different nodes and time periods based on specific criteria. This mitigates having to aggregate log information in your head or having to search through thousands and thousands of logs.

Read More