When monitoring sensitive datasets, our customers commonly ask, “What else should I be monitoring on my mainframe?”

Some of the “usual suspects” to monitor are:

• Enterprise service management (ESM) datasets
• ROC/PARMLIBS
• Encryption keys
• Authorized program facility (APF)-authorized libraries

Users often have a general idea of what to monitor. However, a fundamental question is who should be allowed to read this data. The default access to datasets should not be READ—it should be NONE, unless there is a business requirement for it.

ALLOW and BLOCK Lists

A practical and effective security strategy is to use ALLOW lists instead of BLOCK lists. The latter is often hard to maintain manually, and if someone is not on the BLOCK list, they are immediately allowed. What if a nefarious user elevates their privileges and attempts to access the above datasets? With a BLOCK list, there would be no mechanism to stop them. With an ALLOW list, only specified users will be able to access the dataset and any unauthorized attempts should generate an alert.

Canaries and Honeypots

Another effective defensive tactic is canaries and honeypots. Canaries (inspired by the “canary in a coal mine”) are datasets that, under normal circumstances, should never be touched or altered and serve as a warning mechanism for suspicious behavior. One example is a canary partitioned data set (PDS) such as “SYS1.USERDATA” placed as a decoy for any potential intruder because, to an attacker not familiar with the native environment, it looks like it might be a sensitive dataset. What’s more, the value of canaries isn’t just limited to intruders. Canaries can help detect threats from insiders looking for data in places they should not be.

Honeypots are also deception techniques aimed at tricking adversaries into exploring data or regions of your system they otherwise shouldn’t be. So, then, what exactly is the difference between a honeypot and a canary?

Honeypots and canaries are often conflated terms, though they should be distinguished. Historically, the primary purpose of a honeypot was to observe adversary behavior in a decoy environment over time versus serving as an immediate alerting or warning mechanism like a canary. Therefore, a more appropriate comparison might be a “honeypot LPAR”—where attacker tactics, techniques, and procedures (TTPs) and behavior can be observed over time in a mock environment—with “canary datasets” that serve as warning mechanisms when triggered.

While there are many other ways to monitor sensitive data, the above are some quick wins BMC AMI Security can help implement in your environment today. Sometimes, the most effective detection and response tools aren’t the fanciest and shiniest new things available, but are the ones immediately available to use within the environment.

In the next part of our series, we’ll discuss how Privileged User Monitoring can help you stay ahead of the ransomware threat!

Check out part 1 of this blog: Initial Access and part 2: Privileged Access Management and Zero Trust.

What can we do to stop ransomware from happening in the first place? And how can we stay ahead of adversaries targeting the mainframe?

When thinking about ransomware prevention and privileged access, here are some helpful questions:

• How do you conduct change management?
• How do you track privileged access?
• What if someone has privileged access by default and their account is compromised?
• If you segment your network, why wouldn’t you do the same for your mainframe?

Why is privileged access management (PAM) so important when it comes to ransomware? Just like on any other platform, once an attacker has initial access to the mainframe, they will often attempt to elevate their privileges. This will enable them to explore the environment, pivot laterally, and enumerate sensitive data and security settings with impunity.

We don’t know what we don’t manage, but what if we could effectively manage privileged access on the mainframe with a solution like BMC AMI Security?

During our customer penetration tests, we commonly discover accounts with excessive privileges or older, unused accounts with privileges. Remember: a key principle of zero trust (ZT) security is to never trust, always verify. There is no such thing as a known good entity or account. Instead, all access attempts and existing accounts are assumed to be potential attack vectors and must be verified and re-verified when requesting subsequent access. In addition, this access must be limited to the least amount of privilege required for that specific task, otherwise known as the principle of least privilege (PoLP).

This is a good segue to discuss the difference between PoLP and ZT. Though they are related, they are not the same.

Let’s say I work at a factory on the assembly line. My badge will only allow me to enter the assembly line, because that’s my designated job. I shouldn’t have access to anywhere else in the factory, and if I attempt to do this, my badge won’t allow it. PoLP is simple when applied to roles with minimal privileges.

Now let’s say I’m the manager. My badge should just let me into the assembly line because PoLP dictates I have at least that amount of privilege as a manager. However, my access into this area still needs to be verified and audited by another party—every time. Why? Because maybe I’m not happy with the factory and the reason I want to enter the assembly line at 1 AM on a Sunday is to break some rivets. PoLP “should” let me into that area based on my privileges, but ZT requires that a third party is notified that I’m requesting access to the assembly line. So as a manager, I do have least privileges based on my role, but I really shouldn’t be given any trust implicitly.

Side note: There has been discussion on whether it’s constructive to tell employees, “We don’t trust you.” Rather than phrase it as, “We don’t trust you,” it may help to instead phrase ZT as, “We are doing this because we want to protect you and our entire organization.” Or put differently: “We trust you. We just don’t trust your credentials.” This is 100 percent more reflective of the intentions behind ZT.

Also, the assembly line has cameras for monitoring (visibility/analytics) as part of a ZT model. In addition, when I scan my badge, there’s another layer of authentication (multi-factor authentication, or MFA) that I must pass. All of these are ZT best practices.

The working assumption for all users in a ZT architecture is that they are granted the least amount of privilege (ideally none) as a baseline, as well as after verification. In other words, just because I am authenticated as a certain type of user, this does not imply that my privileges should also change as a result. Instead, my access rights and privileges will be the minimum possible to accomplish a given task.

So how does PAM help with tracking privileged access, enforcing PoLP, and implementing a ZT architecture?

A good PAM implementation must:

• Enumerate and categorize your privileged accounts. Any account that is not part of this established group will NOT have privileged access to the mainframe.
• Define more granular scopes of privilege rather than on an “all or nothing” basis. Just because an account is granted certain privileges, that does not mean it should have unfettered access to every application on the mainframe! Think of this as segmentation for the mainframe.
• Enforce PoLP for privileged accounts, and only when they need them! Define privileged access with limited privileges for specific periods of time.
• Audit access and activity of all privileged accounts.

Locking down privileged access on a PoLP basis and adhering to ZT fundamentals such as “never trust, always verify” will help you prevent a multitude of attacks before they can happen—including ransomware. That said, even with a mature PAM implementation, you must monitor for when an account elevates privileges without authorization. This would be a “smoking gun” alert related to privilege escalation and will help you respond in a timely manner.

In the next part of our series, we’ll discuss how sensitive dataset monitoring can help you stay ahead of the ransomware threat!

Check out part 1 of our series, Normalcy Bias and Initial Access

What one word gets any IT professional’s attention in 2021? Ransomware. In this blog series, we will explore best practices for stopping ransomware before it happens and before an organization needs to activate its backup and recovery plan.

For good reasons, backup and recovery capabilities headline the ransomware security discussion, with many IT teams asking how they can check their backups for integrity, better secure them, and test recovery plans. While these are important questions, ransomware discussions must also include the topics of prevention and detection. What can we do to stop ransomware from happening in the first place, and how can we stay ahead of adversaries targeting the mainframe?

Before we dive into prevention and detection, let’s address some “elephants in the room.”

Normalcy Bias

Some readers who are more experienced with the mainframe might be saying, “But ransomware has never happened on the mainframe!” or “But ransomware would never happen on the mainframe!”

First of all, ransomware has happened on the mainframe.

Secondly, when I thought about this a concept came to mind – normalcy bias. Normalcy bias (or normality bias) is the assumption that since a disaster never has occurred, it never will occur. This can result in the inability of people to cope with a disaster once it occurs. Normalcy bias leads to difficulties reacting to something never experienced before, whether it’s ransomware or some other intrusion. It can cause people to interpret warnings in the most optimistic way possible, seizing on ambiguities to infer a less-serious situation.

Wikipedia adds that normalcy bias is:

“…a cognitive bias which leads people to disbelieve or minimize threat warnings. Consequently, individuals underestimate the likelihood of a disaster, when it might affect them, and its potential adverse effects. Normalcy bias causes many people to not adequately prepare for natural disasters, market crashes, and calamities caused by human error.”

Examples of normalcy bias throughout history include:

• Experts connected with the Fukushima nuclear power plant were strongly convinced that a multiple reactor meltdown could never occur.
• Officials at the White Star Line made insufficient preparations to evacuate passengers on the Titanic and passengers refused evacuation orders, because they underestimated the odds of a worst-case scenario and minimized its potential impact.
• When the volcano Vesuvius erupted, the residents of Pompeii watched for hours without evacuating.

In the context of normalcy bias, is a security “disaster” like a ransomware attack on the mainframe any different from the examples above? Mainframe operators and systems programmers are often strongly convinced that unauthorized intrusions, let alone ransomware, aren’t possible on the mainframe and “could never occur.” Mainframes often have been insufficiently prepared to prevent or detect threats as serious as ransomware because administrators have underestimated the odds of a worst-case scenario occurring.

The threat of ransomware does not discriminate by platform, and security by obscurity is only one layer of security.

With that, let’s dive into our first ransomware enabler on the mainframe: initial access. In the coming weeks, we’ll discuss additional prevention and detection mechanisms like privileged access management, dataset monitoring, and others.

Preventing and Detecting Initial Access

MITRE defines initial access as “techniques that use various entry vectors to gain their initial foothold within a network.” Simply put, adversaries cannot execute code or run ill-intended jobs on the mainframe unless they gain internal access. This sounds self-evident, but if the solution was as simple as, “just stopping them from getting in,” there wouldn’t be so many intrusions today. Something is clearly missing.

Many people would suggest that brute force tools won’t work on the mainframe, but a quick search for “TSO brute force” returns “TSO Brute – The z/OS TSO/E logon panel brute forcer.” According to the script’s author, “Because the logon panel for TSO/E tells you if you have a valid user account vs a valid/invalid password, you can enumerate users. Since you can enumerate users adding a brute forcer was trivial.”

So, why are so many mainframes still relying on password-based authentication?

Credential Re-use and Multifactor Authentication (MFA)

One of the most vulnerable initial access vectors on the mainframe is credential re-use. However, attackers cannot re-use credentials when there is an effective MFA implementation. If you want to stop ransomware before it starts, the best thing you can do is implement and enforce MFA to ensure attackers are not exploiting the “low hanging fruit” in your environment, such as weak passwords or compromised credentials. Simply put, MFA is the most effective way to stop an initial attack on the mainframe.

Initial Access Monitoring

An attacker cannot ransom a mainframe if they cannot get in – full stop. It bears repeating that MFA stops the initial attack and attackers cannot re-use credentials when there is an effective MFA implementation!

Lastly, implement security software which detects and alerts on anomalous logon activity such as password spraying attacks and brute force attempts. A potential brute force attack is an Indicator of Compromise (IOC) indicative of a compromised system on the network attempting to pivot into the mainframe. The same goes for a password spraying attack. If a host on your network is attempting to legitimately access your mainframe and you can detect this in real-time, this provides your security operations team with ample time to investigate and/or remediate the host in question.

The bottom line is initial access attempts should be closely monitored and audited. However, it is nearly impossible to do this in real time without automated detection. BMC AMI Security can monitor and alert you to anomalous logon activity in real time, so you know precisely when someone is attempting to access your mainframe or has done so.

For the next part of our series, we will discuss how privileged access management (PAM) is essential in stopping ransomware before it happens.

This is Part 1 of the MITRE on the Mainframe series. For each part, we will illustrate a tactic of the MITRE ATT&CK framework in mainframe terms and technology. The goal of this series is two-fold: 1) to emphasize that mainframe security is very relevant to contemporary enterprise security, and 2) to review mainframe security within an industry-recognized security framework. In other words, let’s make mainframe security more accessible, understandable, and relatable. To learn more about the MITRE framework itself, check out Grant McDonald’s BMC blog covering the specific tactics, techniques, and goals of MITRE ATT&CK.

NOTE: This blog would not be possible without the research of mainframe security experts such as Phil Young, Chad Rikansrud, the SANS Internet Storm Center, and the security vendors referenced herein. It is being shared here to encourage additional exploration of mainframe security.

During my time in incident response and security operations, I can count the number of times I heard about the mainframe on one hand.

Why mention this? While the mainframe is an important, regular topic at mainframe-focused companies, it is not as mainstream in the contemporary security space, which is dominated by distributed and cloud platforms. Think of security operations centers (SOCs) of all sizes. They are likely monitoring devices ranging from network to endpoint, data storage, etc. Yet how many have given serious thought to “big iron?”

One would think that mainframes would be part of the greater security conversation in most large organizations, at least to the extent of “should we be integrating the mainframe more?” However, based on my observations and experience within security operations, this is often not the case. What is ironic is that the mainframe qualifies as all the device types above—a data warehouse, a high-performance computing center, and a network hub—yet it is rarely considered as equally important.

So why is this and how can we overcome it? There is ample thought leadership about this question and mainframe-specific security challenges, both operationally and perceptually. Here are a few recommendations:

Why zOS Mainframe Security Matters by Chad Rikansrud

The Missing Link in Your SOC: Secure the Mainframe by Christopher Perry

Securing the Mainframe: How Companies can Empower Security Analysts to Protect the Backbone of Their Enterprise by Christopher Perry

Without question, the lack of mainframe inclusion in security considerations is a layered issue and I encourage everyone in the security space to consider its causes. There is certainly not a simple answer, but the nuances of the challenge can help those of us in security be more prepared.

With that said, let’s take a look at the relevance of mainframe security and review it within the MITRE ATT&CK framework.

Part 1 – Reconnaissance

In a previous life, if you told me: “Eddie, we need you to monitor our enterprise’s most critical server. In fact, we can’t even afford to have bad actors know where to look for it. Go secure it.”

I would likely respond with: “Absolutely. So… where is it?”

Yes, it is probably in the COLO (co-location center, or data center where equipment, space, and bandwidth are available for rental to retail customers). However, this is also the first question an adversary will ask. Irrespective of whether the target is a mainframe, a public facing server, or even a network connected peripheral, any adversary must first know where to look. This is where the tactic of Reconnaissance comes into play and why it is the first tactic covered in the MITRE ATT&CK Framework Matrix for Enterprise.

NOTE: MITRE ATT&CK Tactics are not sequential, meaning just because Reconnaissance is categorized first does not mean it necessarily happens first in practice. For example, an adversary might first gain access to credentials (Credential Access) then proceed to conduct Reconnaissance on the internal network. Or they may conduct internal recon again after escalating their privileges, granting them access into more sensitive areas of the network.

Per MITRE:

“Reconnaissance consists of techniques that involve adversaries actively or passively gathering information that can be used to support targeting. Such information may include details of the victim organization, infrastructure, or staff/personnel. This information can be leveraged by the adversary to aid in other phases of the adversary lifecycle, such as using gathered information to plan and execute Initial Access, to scope and prioritize post-compromise objectives, or to drive and lead further Reconnaissance efforts.”

Now let’s discuss some of the Reconnaissance tactics in the context of the mainframe.

Search Open Websites/Domains

“Mainframes are searchable on the internet? Sounds unlikely.”

A free and useful reconnaissance tool for searching the Internet of Things (IoT) is Shodan. Shodan is a search engine that lets the user find specific types of computers (webcams, routers, servers, etc.) connected to the internet using a variety of filters. Some have also described it as a search engine of service banners, which are metadata that the server sends back to the client. This can be information about the server software, what options the service supports, a welcome message or anything else that the client can find out before interacting with the server. Shodan collects data mostly on web servers (HTTP/HTTPS – ports 80, 8080, 443, 8443), but also collects on mainframe relevant ports such as FTP (port 21), SSH (port 22), and Telnet (port 23, 992, 1023, and 2323).

According to a July 2017 TrendMicro report on publicly exposed mainframes:

“Shodan data showed that legacy mainframes, particularly the IBM OS/390 (zSeries) and IBM AS/400 (iSeries) as well as their corresponding FTP and web servers, were exposed. The data also revealed that telecoms and ISPs were the industries with the most number of exposed/online legacy mainframes.”

For illustration, the report also provided figures on types of systems exposed and geographic breakdown:

Exposed mainframe and related services by model (Credit: TrendMicro)

Top countries with exposed mainframes and related services (Credit: TrendMicro)

Exposed zSeries terminal (Credit: TrendMicro)

Knowing the above, an adversary could learn Shodan filters in minutes and start reconnaissance against public facing mainframes. Following Reconnaissance, they could probe listening services to try to gain unauthorized access using common mainframe services like FTP or Telnet.

For example, unsecure FTP can serve as an entry point from which attackers can gain authorized access to mainframes. FTP is typically used to upload transaction commands in the mainframe, such as Job Control Language (JCL), which is equivalent to a bash script in Linux^® or batch file in Windows, and Restructure Extended Executor (REXX), which is similar to Python. If an FTP is successfully compromised and accessed, attackers can upload a malicious JCL program. If given executable permission to run it and with enough privileges in the terminal, it can execute arbitrary commands to compromise a mainframe.

All of this just from knowing where to look!

In addition, mainframe security expert Philip Young (aka Soldier of FORTRAN) discovered that using specific keywords, not just filters, and selectively modifying them could yield further results. This is due to the specific text that HTTP banners might display being different from what one might expect. To learn more about how Shodan uses banner grabbing to find public mainframes, check out Young’s blog post, Finding Mainframes on Shodan.

Active Scanning (Scanning IP Blocks/Vulnerability Scanning)

An essential tool in any security professional’s kit is Nmap, a free and open-source utility for network discovery and security auditing. Using a simple and intuitive command line interface, users can leverage Nmap to scan specific IP addresses and CIDR blocks for open ports, listening services, and even specific vulnerabilities. While not a dedicated vulnerability assessment tool, this capability speaks to Nmap’s versatility. Not only that, Nmap leverages the Lua scripting language for a variety of security use cases—including Reconnaissance of the mainframe! (For those who prefer a graphical user interface (GUI), Nmap also has a nice overlay called “Zenmap” that is quite popular.)

For example, Young has written Lua scripts that enumerate IBM^® CICS^® transaction IDs, CICS User IDs, NJE (Network Job Entry) target node names, TN3270 hidden fields, TSO accounts, VTAM application IDs, and even screen grab TN3270 banners, all using Nmap. Users can even go beyond Reconnaissance and use Nmap for brute force attacks against NJE and TSO. These tools and more are all publicly available at Young‘s github repository and have been instrumental in building awareness around mainframe security.

Even prominent security vendor SANS has demonstrated the availability of legacy mainframes on the internet. Without any custom scripts, the SANS Internet Storm Center leveraged Nmap to identify Telnet and SSL Telnet ports. SANS discovered that mainframe IBM^® z/OS^® hosts are well fingerprinted by Nmap and, though they are often labeled as OS/390, were still very findable.

If you’re looking for more reconnaissance tools to experiment with, another powerful tool is masscan. Creator Robert David Graham claims that masscan can scan the entire internet in under five minutes, transmitting 10 million packets per second, from a single machine. It goes without saying that if you would like to experiment with tools such as Nmap or masscan, please do so in a lab environment and never scan IP blocks indiscriminately.

One important note is that Nmap is not just an external scanning tool but is equally useful for internal scanning once an adversary has a foothold in the network. Therefore, knowing network trust relationships (to be discussed below) and which systems might serve as potential pivot points for an adversary also becomes crucial in preventing effective internal reconnaissance by an adversary.

Gather Victim Host/Identity/Network/Org Information

At this point you might be thinking, “All of the above sounds interesting, but surely our mainframe would never be exposed publicly. We have nothing to worry about!”

Unfortunately, reconnaissance goes a bit deeper than just the “low hanging fruit” of publicly exposed systems. As MITRE aptly points out, much of reconnaissance is passive information gathering that may never involve a tool such as Nmap or Shodan. That is, it involves gathering host, identity, network, and organization information.

Here is the good news: users can make a difference in hardening the organization’s security posture for each of the above categories.

Host: Practicing good cyber hygiene, such as keeping software, firmware, and configurations of access tools that may involve the mainframe (directly or indirectly) up to date, will prevent an adversary from potentially exploiting a vulnerability found in one of these resources. Application whitelisting and security configuration management (SCM) enforced at the enterprise level are very effective ways to ensure secure baselines are maintained across the enterprise. While this may not prevent zero-day attacks, it will certainly reduce host attack surface significantly. And it is often the pivot (see: Lateral Movement in MITRE) from compromised non-mainframe systems that present the greatest threat.

Identity: Securing potentially sensitive information such as personal e-mail addresses, employee PII (personally identifiable information), and credentials will also reduce any potential attack surface. Keeping this information protected as much as possible inside an internal or corporate network, ideally with multifactor authentication, will make reconnaissance more difficult for an attacker. Regarding credential security, an increasingly common practice in enterprises today is the use of password managers (or password “vaults”) that store and organize usernames and passwords while offering security capabilities like the generation of complex passwords unique to each account, secure credential exchange, and real-time alerts when old or weak credentials are exposed online.

Network: While more mature enterprises may not be overly concerned about public-facing mainframes, they should be concerned about the potential for “insider threats” and lateral movement (to be covered in a future post) to the mainframe once an attacker is inside the environment. Most, if not all, mainframe users today are using terminal emulation from a distributed platform such as Windows to log into the mainframe. One way to ensure that internal reconnaissance will yield limited results is to map network trust relationships in Active Directory (AD) environments using tools like Bloodhound. The better one knows their internal network, the more they can prevent an attacker from using these tools to identify privilege escalation paths. With a privileged account, an attacker can likely gain additional insight into the environment or, at worst, discover a potential attack vector to the mainframe.

Organization: Adversaries will often probe open-source intelligence to find potential high value targets for social engineering or phishing attacks. While it is certainly understandable to post one’s generic job title on LinkedIn, it would not be wise to go into any technical detail regarding scope of work or types of systems accessed. The unfortunate reality of the world today is that all of our public-facing activities become reconnaissance assets for adversaries. While it is not practical to stay out of public life, every user should exercise a “zero trust” posture when communicating with unknown parties and uploading data of any kind, regardless of how trusted the recipient may be.

The mainframe has long benefitted from “security by obscurity.” However, as the complexity of IT ecosystems increases, it is not as if the mainframe is simply being left out of the operational equation. If anything, it has become more crucial than ever as online transactions and the need for lightning-fast and reliable data processing continues to increase in an interconnected world. Therefore, increased discussion of mainframe security in the security community overall is needed. One way to promote this is by making mainframe security more accessible, understandable, and relatable for everyone.

This is precisely what the MITRE for Mainframe series aims to do. For our next MITRE for the Mainframe post, we’ll review Initial Access and how an attacker can gain a foothold on your mainframe.

Though ubiquitous in information security today, the term SIEM (security information and event management) was coined by Gartner in 2005—just 16 years ago! Since the scope of this article is to suggest best practices, it will not go into depth of what SIEMs can and should do. As security professionals might tell you, it’s not what the tool claims to do (“You’ll see the rats scurry away once you turn on the light!”) but rather how thoughtfully it is implemented, the extent to which it is mastered, and how it is leveraged.

Here are five best practices for SIEM users:

1. Clarity of strategy—more money more value? Not quite

The appeal of managed security services (MSS) and “security in a box” seems too good to be true. After all, who wouldn’t want to meet compliance requirements through a single purchase?

Let’s use the fictitious Acme Corp. as an example. Acme’s chief information security officer (CISO) mandates that the company must decide upon, install, and maintain a SIEM to meet compliance requirements. Perhaps this is what the board demands, and showing timely results is priority number one. Moreover, the CISO stays up at night thinking about their next audit and a lack of visibility into their environment. With this kind of pressure, a conveniently managed, do-it-all monitoring solution sounds perfect.

A fictitious security vendor, Miracle Security, makes a compelling case to Acme. Miracle claims that its OOTB (out of the box) SIEM solution will provide the analytics, alerting, and compliance reporting Acme requires. On top of that, Miracle will add its MSS (third-party security support) and administrative support to maintain the platform. However, what the CISO and the security team don’t realize is that this “administrative” support might mean that Miracle is the only ones with the knowledge and capabilities to access and troubleshoot the backend—for an additional fee.

Acme’s CISO is sold and informs the security team that the security operations center (SOC) will cooperate with Miracle to stand up and leverage Miracle’s proprietary SIEM, cleverly named “Magic.”

A massive initial effort is undertaken across the enterprise to ingest every possible data source into Magic. The mentality is: more is better—more data sources, more visibility, more alerts, and more investigations.

Once Magic is deemed “operational,” it has hundreds of data sources of differing types. The SOC has a handful of analysts who have varying levels of familiarity with Miracle, but ultimately they have not been sufficiently trained on how to improve Magic or the countless complex features Miracle pitched in its sales proof of concept (POC).

Alerts begin to flood the SOC. Most, if not all, are low-fidelity. Miracle’s MSS complies with its service level agreement (SLA) to raise alerts regardless of accuracy so the organization does not lose “visibility.” Also, any time Magic has a critical backend issue (which was conveniently not discussed as a possibility in the POC), Acme must open a support ticket to an overseas team that can take hours or even days to remedy. Analyst burnout becomes common.

And the worst part is that Acme is locked into a two-year contract with Miracle.

While the above example is fictitious and perhaps may even seem extreme, the reality is that numerous security teams believe that spending a significant amount on technology and services will somehow mature the organization overnight.

Sometimes, great things really are free.

2. “Show me the metrics!” (quality over quantity)

To underscore the above, security teams also often fall into “the metrics trap,” and for good reason. Leaders must continually and consistently present metrics to stakeholders. Metrics in and of themselves are not negative things. In fact, quite the contrary. Metrics are invaluable—but rarely measured correctly in the context of, “what will make our security team more effective?” The motive behind presenting metrics may often lose sight of this and, as a result, become increasingly muddled.

A discussion of metrics is needed because, practically speaking, they are often what drive SIEM implementation and design. Rather than asking, “How many alerts are we generating?” the fundamental question must be, “Are we creating high-fidelity alerts regardless of quantity?” The former focuses on quantity, while the latter focuses on quality.

While the above may sound self-evident to seasoned security professionals, the reality of many SOCs is that this mentality simply does not happen. If it did, “alert fatigue” would be far less common than it is today. Simply searching for literature on “SOC alert fatigue” generates numerous articles specific to the topic written by prominent security vendors.

What often prevents security teams from making the shift from quantity to quality is uncertainty—both in terms of visibility and job security.

The mentality often is: It’s better to have an abundance of disparate, disjointed visibility than a smaller, high-fidelity amount, right? (The answer is no.)

Moreover, many security leaders fear turning off the hose due to optics—or organizational metrics. How can one say they are doing their job when the alert count went down 80 percent last quarter? Never mind that analysts can now conduct end-to-end investigations with high-fidelity, intelligence-rich indicators of compromise (IOCs) and experience massive professional growth in the process—leaders must still be prepared to explain these changes in “metrics.”

In short, security teams need the requisite foresight and maturity to understand that the quality of data (and analytics) in the SIEM must take precedence over visible quantity.

3. Total ownership

Executive leaders, perhaps more than anyone else, understand that risk cannot be transferred. In the example of Acme Corp., I intentionally highlighted that Acme committed to a services contract with an outside vendor for alert analysis and backend administration. While this might seem like the safest and most convenient path forward for many teams, the reality is that the more that control is removed from the security team, the more the team will experience operational friction during both day-to-day and crisis situations.

In addition, the less control the security team has over the data sources that the SIEM requires to be effective, the more difficult it will be to create high-fidelity alerts. In the example I used above, Acme stood up its SIEM with a massive initial effort, which was followed by a “set it and forget it” approach. While this is not always the case, it is often the path of least resistance for many organizations when standing up a SIEM because it is seen as a one-time cost. However, the reality of effective SIEM implementation is that it must be treated as a lifelong commitment, not simply an upfront cost. Too often, security teams realize this too late and are trapped in binding contracts or without the requisite access or personnel to succeed.

Realistically, the security team may not have full control over every asset within the SIEM. However, they should be granted the requisite control and access needed through a shared platform. This could be a security orchestration, automation, and response (SOAR) solution, or even as simple as remote access with limited privileges. Without this, it is impossible to effectively improve the quality of data ingested by the SIEM.

Finally, the security team must own the SIEM as the subject matter experts (SMEs) of the product. Ultimately, the SIEM is the security team’s responsibility and the closer the center of control is to the team, the more autonomy and confidence they will experience when leveraging the product.

4. Ingest judiciously (know when to say no)

In a hurried effort to turn the lights on, Acme ingested data sources into its SIEM at a massive scale. The mentality appeared to be one of catch-up, where the faster Acme could claim to stakeholders that it had “full visibility” of the environment, the more secure it would be. Even if a security leader in the organization suggested pumping the brakes and instead focusing on whether the data ingested was high-fidelity, it is quite possible they would have been overridden. However, security leaders of all levels are paid to lead—and this means knowing the right path forward and when to say no.

Simply put, Acme’s approach was a recipe for SIEM disaster.

A more prudent approach may have been for Acme to master its own island first. The security team could have ingested and mastered their immediate IT ecosystem, using it as a proving ground for the team. Starting from the inside out at an incremental pace will ensure that the SOC does not experience burnout and can grow in both confidence and capabilities at a more manageable level.

Once you are successfully able to manage the basics you can extend your security operations center purview to other critical servers like the mainframe, which run core business applications and commonly don’t have the same security continuous monitoring they require.

No artist begins a masterpiece by throwing every color of paint on the canvas and attempting to salvage it afterward. They are masterfully thoughtful, intentional, and creative in how they build their vision.

It’s the same with a security team and their tools.

5. Learn by doing

Finally, the best way to leverage any SIEM solution is simply to master it. Note this is not the same as “use it,” as even a bot can leverage a modern graphical user interface (GUI)-based SIEM in some way.

With the advancement of security tools in recent years, many of them can perform manual and repeated functions in a security analyst’s job. This is not simply a SIEM phenomenon. SOAR, endpoint detection and response (EDR), and IT service management (ITSM) platforms all attempt to streamline manual processes as much as possible and present analytics in an easily digestible format. These are all good things that make security teams more effective.

However, any tool is only as effective as its user. SIEMs require regular care and maintenance—and upgrades, when appropriate. Security teams cannot expect to passively reap the benefits of a SIEM without actively seeking to master it. This is how a SIEM can quickly become a deprecated and irrelevant tool in the security team’s budget, rather than one integral to enterprise security.

A SIEM is more effective with one “power user” than ten passive users who expect it to simply present data and alerts for triage. It is the responsibility of every member of the security team to become a power user, rather than expect one or two individuals to assume this role.

These are just five principles that can help your organization successfully implement a SIEM solution (if it chooses to do so) in the most prudent manner possible. To learn more about how BMC can help your organization integrate your “backbone of the enterprise” into the SIEM with a tailored and strategic approach, visit the BMC AMI Security web page.

Privileged users have access to the most sensitive areas of your mainframe environment. To keep them protected and help prevent credential theft or threats from a malicious insider, you need to go beyond monitoring solutions alone. BMC is excited to announce two new, innovative detection capabilities for BMC AMI Security that will enhance enterprises’ ability to monitor, detect, and respond to threat activities involving privileged users: Unix System Services (USS) privilege enrichment and Supervisor Call (SVC) screener.

Unix System Services (USS) privilege enrichment

Ever wonder if there are new superusers in your Unix subsystem? What if a user suddenly became a superuser with keys to the kingdom and you weren’t aware of it? If a tree falls and no one hears it, did it really produce a sound? (The answer is yes.)

From a security perspective, USS can be a valuable resource for attackers on the mainframe. While the intricacies of z/OS and its numerous applications might be foreign to an attacker, the Unix subsystem offers a familiar environment in which attackers can explore and experiment.

Security teams must maintain visibility into and situational awareness of changes in permissions and access. With the addition of USS privilege enrichment, BMC AMI Security now gives mainframe enterprises that visibility and situational awareness, including visibility into a key subset of privileged users. In addition, BMC AMI Security integrates with modern security information and event management (SIEM) solutions to ensure security teams can leverage this and other critical mainframe security intelligence within their respective analytics engines.

Supervisor Call (SVC) screener

In addition to privileged users, security teams must also have visibility into privileged “calls” on the mainframe. A call is simply the process of executing another predefined routine or set of instructions. Even without access to a privileged account, an adversary can intercept an authorized SVC and use it do anything they want on the mainframe. Thankfully, BMC AMI Security now checks for anomalous SVCs to ensure they are not misused, continually scanning the SVC table to ensure that SVCs are only present in sensitive areas of the mainframe and no other areas where an attacker could leverage them for nefarious purposes.

The features above are just two of many capabilities BMC AMI Security provides to detect and respond to threats on the mainframe. To learn more about how USS privilege enrichment and SVC screener work, read our new BMC whitepaper here. To learn more about how BMC AMI Security helps enterprises detect and respond to threats on the mainframe, watch this video.