Fitted Security

Fitted Security

Avoiding the pitfalls of the security trends to design a security strategy that fits your environment and optimizes your posture given the available resources.

Many organizations design their cybersecurity strategy and decide what solutions to purchase based on industry trends and best practices. The outcome is often imbalanced and inappropriate to the organization’s risk profile and security needs.

Best-practice implementations are usually one-size-fits-all and not tailored to the specific environment. Being predictable, there are usually tools and guides on the internet that can defeat them. A generic approach of this nature also fails to leverage advantages readily available when examining the specifics of the environment.

Many solutions come with out-of-the-box security. They contain built-in policies and signatures designed for a low false-positive rate in any environment. These have difficulty identifying attack variations and can never identify other vectors, resulting in a weaker defense.

This paper is about how to do security differently.

Perimeter Vs. Data Centric

Most security solutions fall into one of two categories: Perimeter security or Data-centric security.

Perimeter security aims to prevent attackers from getting into the network and accessing internal systems. A compromised desktop is not a data breach, but once attackers have this access, they can take the next step and try to gain access to the application or the database. A data breach would only occur if the attackers can navigate from that compromised desktop to the data.

Perimeter security has two strategic limitations:

  • Internal threats – when a threat is already inside the network and behind the perimeter, it cannot be secured by these types of defenses. The same applies to threats outside the network with VPN access (.e.g. partners, consultants, and more).
  • Statistical defense – perimeter protections almost always aim to reduce the number of penetrations but not to prevent them altogether. Regardless of how good our spam filters are, we continue to get spam emails. No matter how good our personnel training is, people still click on those phishing emails.

Data-centric is a methodology that revolves around the data. It starts with where the data is stored – the database and expands outwards to the applications that process that data.

Data-centric security includes database security, application security, IAM, and more. A strong data-centric posture can prevent a data breach regardless of how many attackers penetrated the perimeter. For example, cloud-based applications rely mainly on data-centric measures.

Perimeter security is a parallel defense where attackers only need to breach one of the measures to get in. Attackers that fail to penetrate the firewall can try the mail system, social engineering, etc. Perimeter security is as strong as its weakest link.

Data-centric security is a layered security resulting in a serial defense where attackers must penetrate all the layers. A successful application breach that fails to execute an attack against the database is a failed attack. Data-centric security is the last line of defense and aims to be as air-tight as possible.

Perimeter and Data-centric defenses are not mutually exclusive, and well-balanced strategies will include both.

Landscape Considerations

When building a security strategy, we must consider the threats we perceive as relevant. For example, are we worried about external threats, internal threats, or both? If internal threats are a significant concern, perimeter security will not be effective against those, and we should beef up the data-centric components.

We must also consider the effectiveness of different measures in the current landscape. For example, as more and more people work remotely, network security and endpoint security are less effective. Once people work from home, they are outside the corporate firewall and use their home computers. With minimal control over all these remote mini-offices with VPN connections, our perimeter defense becomes weaker than expected.

BYOD (Bring-Your-Own-Device) poses a similar challenge where many uncontrolled and insecure phones and tablets roam the corporate network inside our perimeter.

As the modern landscape changes and the effectiveness of perimeter controls diminishes, there’s a growing shift to internal defenses. Part of this shift includes a redefinition of the perimeter line – protecting the data center network is more important than the corporate network.

Asset Considerations

There are several considerations when choosing which systems to focus our defenses and how to allocate resources:

  • Risk – some systems pose a higher risk than others. For example, a firewall is necessary because, without it, we will have countless attackers inside our network. We need to defend the application because all the people using it or with network access to it form a large surface area. We must also protect our database because it stores all the data, and a breach would be catastrophic.
  • Effectiveness – some systems are easier to secure with better results, while others can be expensive to protect or have limited security benefits. For example, firewalls are an effective measure and are cheap and easy to deploy – that’s an easy choice. Application or database security (depending on the solution used) could be difficult or expensive to deploy but with good results. IAM can be costly to deploy but with limited value.
  • Attack paths – some systems are on a critical path between the attackers and the data. Others are on paths that attackers could bypass. For example, an attacker must communicate with the database to extract the data. An attack is unlikely to succeed without it. However, whether an application is on such a path depends on the environment. Sometimes, the main path to the data is through a single application. In other cases, multiple applications or direct database connections offer alternative paths.

Balancing the risk, effectiveness, and attack paths is a central consideration in cybersecurity strategy, and there are multiple balancing methods. However, it’s important to remember there are many variables. For example, the effectiveness of the security depends on the solution and technology you’re evaluating since different solutions will differ in cost and effectiveness.

IDS and IPS

Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS) are fundamentally different methodologies in security.

IPS aims to prevent attacks and breaches. These are classic security systems like firewalls, users & passwords, etc. IPS are critical components in any security strategy.

In contrast, IDS aims to detect attacks and alert or report on them. These include measures like auditing, SIEM, etc. IDS are also a critical component in any security strategy as they inform security personnel, allow them to initiate a response, and provide forensic information.

It’s important to understand the core differences between IPS and IDS:

  • Tolerance for false positives.
    False positives in IPS mean the system prevents users from performing legitimate activities. Therefore, IPS cannot tolerate false positives.
    False positives in IDS mean that reports or alerts require investigation by security personnel while users continue doing their jobs. While we don’t want too many false positives, most IDS are designed and calibrated to have a certain level of false positives.
  • Response time.
    IPS must determine whether activities are valid before letting them through. A slow IPS means IT systems have longer response times, and users complain. An IPS is, therefore, always designed to use real-time algorithms capable of making split-second judgment calls.
    IDS, on the other hand, can take their time to report or alert. IDS usually use more complex algorithms and can analyze large volumes of data to identify intrusions. They can refer to historical information or wait for future events to occur.
  • Circumvention.
    When an IPS system prevents an attack, the attacker is inevitably aware of the failed attempt and can try again. Therefore, attackers constantly challenge IPS systems until they find a way to penetrate them.
    IDS inform security personnel of the attack allowing them to respond in various ways. Responses can include taking systems offline, diverting attacks to honeypots, tracing the attack back to its source, and more. In all cases, attackers don’t get a second chance to try again against an identical defense. IDS systems are, therefore, much more difficult to circumvent.

Consequently, while IPS could prevent an intrusion, IDS is more likely to detect it and less likely to be circumvented. It’s always recommended, when possible, to deploy both types of systems. Deploy an IPS to block most attacks and deploy an IDS to detect the ones that got through.

Tailored Security

Every environment is different. Differences include the application architecture, technology stack, the number of users, administrator access, and more. Other parameters include the user roles, the programs in use, the network segments, the types of data, the activity profiles, etc.

Leveraging such parameters while implementing preventive and detective measures yields more effective results. Such tailored security cannot be out of the box as it requires evaluation, consideration, and planning. However, it’s vital for achieving high effectiveness in attack detection and a low false positive rate.

Customizing security this way takes time and effort, and there’s no magic bullet. But the results are far more likely to withstand an attack and prevent a data breach.

DCSA

Data-Centric Security Assessment is a service offered by Blue Core Research to help security departments quantify the risk to each of their systems and evaluate the effectiveness of different controls and strategies.

DCSA is an interview-based evaluation that uses your opinion about your systems. It will combine multiple parameters about each system in your environment and yield your risk level.

DCSA aims to help you choose the solutions and strategies with the most impact on your security to minimize the risk.

Final thoughts

The quality and strength of your security strategy depend on the time and effort that went into it. You will have a good security posture if you have a good balance between your perimeter and your data-centric, you created layered security, you combined both IPS and IDS on every system with a proper response strategy, you tailored your solutions to each environment, and you spread your resources according to the risk, effectiveness, and attack paths attackers are likely to follow.

That sounds like a lot, but it’s not that difficult. However, it means not following trends and buying solutions just because they are in fashion. It means putting efforts into implementations and not just looking to follow best practices. That requires effort and careful thought, but it’s the best way to lower the risk of a data breach.


SQL Injection Attack Detection

SQL Injection Attack Detection

This is a true story of a SQL injection attack on our website. Learn about the attack and why the Core Audit anomaly analysis database defense is the most effective way to combat this type of threat.

Introduction

We got an alert two days before New Year’s. It was shortly after midnight on December 30, 2021. It was a daily anomaly alert relating to the database backend of an old website, but it was clearly an attack.

As it later turned out, this was the first of several such attack attempts. There were three more in January of 2022, two more in February, and one more in August, October, and November. All in all, nine similar attacks over the course of a year.

Background

We use WordPress (an open-source content management system) on many of our websites and always with a MySQL backend (the most popular setup). The website in question was old, and due to compatibility problems, we haven’t updated some of the software components in a while. So when I first saw this alert, it seemed highly plausible that there was a vulnerability that led to a successful attack.

As it later turned out, this was a false positive. The reason for this false positive was that in addition to an old version of WordPress and plugins, this website also used an old version of Core Audit. But more on this later.

None of our websites contain sensitive information, but as this paper will show, protecting the database of any application with Core Audit is a highly effective means of detecting attacks and protecting the application.

The Anomaly

The anomaly alert had 168 lines, and the first line was this:

SELECT * FROM wp_users WHERE user_login = '') UNION ALL SELECT NULL-- HupP'

While each line was different, every line started with one of these:

SELECT * FROM wp_users WHERE user_login =''

SELECT * FROM wp_users INNER JOIN wp_usermeta ON user_id = ID WHERE meta_key = '' AND user_login = ''

What made it clear that this was an attack were the many end variations of the SQLs that looked like these:

;SELECT SLEEP(9)#' LIMIT 9

) AND SLEEP(9) AND (\\''=\\''

WAITFOR DELAY \\'' AND \\''=\\'' LIMIT 9

;SELECT SLEEP(9)#'

);SELECT PG_SLEEP(9)--'

;SELECT PG_SLEEP(9)--' LIMIT 9

);WAITFOR DELAY \\''--'

;WAITFOR DELAY \\''--' LIMIT 9

) AND 9=(SELECT 9 FROM PG_SLEEP(9))

UNION ALL SELECT NULL-- HupP'

) UNION ALL SELECT NULL-- HupP' LIMIT 9

UNION ALL SELECT NULL,NULL,NULL-- iIWs'

UNION ALL SELECT NULL,NULL,NULL,NULL-- ynbe'

Bear in mind that the empty strings ('') and the 9’s are not part of the original SQL. They relate to how the Core Audit security repository operates. This repository automatically collects all the SQLs in the database, so to reduce storage space and eliminate anomalies from embedded literals, it automatically strips all the numbers and strings.

The attempts listed above were scanning for a SQL injection vulnerability. They were trying to detect whether SQL injection was possible and discover details that would facilitate an attack:

  • The various sleep/delay statements would only work on particular databases. So a delayed response tells the attacker both that the injection was successful and the type of database used.
  • The various UNION and NULL permutations were trying to determine the number of fields in the query and whether they could append data from other tables.

In addition to many more variations of SLEEP and UNION, there were other colorful expressions like:

) AND (SELECT 9 FROM(SELECT COUNT(),CONCAT (0x7178707671,(SELECT (ELT(9=9,9))),0x71717 67171,FLOOR(RAND(9)9))x FROM INFORMATION_SCHEMA.CHARAC

) AND 9=CAST((CHR(9)||CHR(9)||CHR(9)||CHR(9)||CHR(9))||(SELECT (CASE WHEN (9=9) THEN 9 ELSE 9 END))::text||(CHR(9)||CHR(9)||CHR(9)||CHR(9)||C

) AND 9=CAST((CHR(9)||CHR(9)||CHR(9)||CHR(9)||CHR(9))||(SELECT (CASE WHEN (9=9) THEN 9 ELSE 9 END))::text||(CHR(9)||CHR(9)||CHR(9)||CHR(9)||CHR(9)) AS NUMERIC) AND (\\''=\\'')

;SELECT DBMS_PIPE.RECEIVE_MESSAGE(CHR(9)||CHR(9)||CHR(9)||CHR(9),9) FROM DUAL--'

AND 9=CONVERT(INT,(SELECT CHAR(9)+CHAR(9)+CHAR(9)+CHAR(9)+CHAR(9)+(SELECT (CASE WHEN (9=9) THEN CHAR(9) ELSE CHAR(9) END))+CHAR(9)+CHAR(9)+C

) AND (SELECT 9 FROM(SELECT COUNT(),CONCA T(0x7178707671,(SELECT (ELT(9=9,9))),0x717 1767171,FLOOR(RAND(9)9))x FROM INFORMATION_SCHEMA.CHARACTER_SETS GROUP BY x)a) AND (\\''=\\'')

) AND 9=CONVERT(INT,(SELECT CHAR(9)+CHAR(9)+CHAR(9)+CHAR(9)+CHAR(9)+(SELECT (CASE WHEN (9=9) THEN CHAR(9) ELSE CHAR(9) END))+CHAR(9)+CHAR(9)+CHAR(9)+CHAR(9)+CHAR(9))) AND (\\''=\\''

These SQLs are clearly unusual and seem to attempt to bypass a SQL injection protection system like a WAF.

Forensics

We experienced an attack. The alert left no doubt about that. The two remaining questions were:

  • Was the attack successful?
  • Which part of the application was targeted?

Database Forensics

The first question was easy to answer. I started by locating the queries in the reduced SQL forensic view. The reduced SQL repository has a 5-minute resolution, and all these SQLs executed within the 5-minute window of 8:20 am to 8:25 am.

Once I located the queries, I also saw the good news – they were all successful (no errors), and the number of rows retrieved was zero for all.

Why are successful executions good news? Because this attack was trying to test whether the application was vulnerable to SQL injection. In this scan, most of the queries were supposed to fail, with the few successful ones indicating the method to exploit a vulnerability. For example, the SQLs with PG_SLEEP() could never be successful on our MySQL database since this function only exists in PostgreSQL databases. Therefore, successful executions mean the injection attempt failed to modify the SQL construct.

Additionally, these SQLs didn’t retrieve data, so there was no leak. While most of these SQLs were not attempting to extract anything, it’s comforting to know nothing was retrieved.

In other words – this attack failed to break through the literal boundary. We’ll get back to this subject later and also answer the more interesting question of why we got the anomaly alert in the first place.

Application Forensics

Now that we have more information, it’s easy to search the Apache logs for more details on the attack and what it targeted.

The attack was between 8:20 am and 8:25 am and accessed the wp_users table. Looking at the Apache log, we can see this attack started at exactly 8:20 am:

[29/Dec/2021:08:20:00] "GET /wp-login.php?log=1&pwd=-9696%20UNION%20ALL%20SELECT%2024%2C24--%20ptzf"

This attack was a GET request to the wp-login.php script. That is the WordPress login page. The attack delivered its injection attempt through the password field that, in this first attempt, included:

-9696 UNION ALL SELECT 24,24-- ptzf

The last attack attempt was using this POST request at 8:21:51 am:

[29/Dec/2021:08:21:51] "POST /wp-login.php?Phws%3D5963%20AND%201%3D1%20UNION%20ALL%20SELECT%201%2CNULL%2C%27%3Cscript%3Ealert%28%22XSS%22%29%3C%2Fscript%3E%27%2Ctable_name%20FROM%20information_schema.tables%20WHERE%202%3E1--%2F%2A%2A%2F%3B%20EXEC%20xp_cmdshell%28%27cat%20..%2F..%2F..%2Fetc%2Fpasswd%27%29%23"

The Apache logs don’t record the POST parameters, but we can see this payload on the request:

Phws=5963 AND 1=1 UNION ALL SELECT 1,NULL,'<script>alert("XSS")',table_name FROM information_schema.tables WHERE 2>1--/**/; EXEC xp_cmdshell('cat ../../../etc/passwd')#

This payload is a little funny as it contains a SQL injection with a cross-site scripting scan (alert(“XSS”)) and an attempt to have SQL Server execute a shell command (EXEC xp_cmdshell) with a Unix/Linux command printing the content of a Unix/Linux password file (cat …/passwd).

That is a mix of attack fragments that could never work together. And there are several other things wrong with this last request and payload.

That indicates the person running the attack had little understanding of what they were doing. Combined with the fact that the whole scan lasted just under 2 minutes, it suggests this was a script or, more likely, several scripts they downloaded off the internet and executed against various websites.

False Positive

So why did the attack fail, and why did we get an anomaly alert anyway?

A SQL injection attack attempts to modify the SQL construct by breaking through the literal boundaries. In other words, when a SQL contains a literal like this:

SELECT * FROM wp_users WHERE user_login = 'JOHN'

A SQL injection attack attempts to send a string other than “JOHN” so the SQL construct will change. For example, the string “X' or 'Y'='Y” will result in this SQL:

SELECT * FROM wp_users WHERE user_login ='X' or 'Y'='Y'

By changing the SQL construct and adding or 'Y'='Y', the database will run something not intended by the developer who wrote the code. Putting a tag (') in the input broke through the literal boundary and allowed the attacker to alter the SQL construct. Escaping literals before embedding them into a SQL prevents this vulnerability.

In the SQL standard, you can escape tags (') by using double tags (''). When escaped, the above example will yield:

SELECT * FROM wp_users WHERE user_login = 'X'' or ''Y''=''Y'

In this case, the database will compare the user_login field to the entire string, and the word OR is just part of the user name, not part of the SQL construct.

WordPress must have escaped the input correctly in our attack, and the SQL construct was not modified. That’s why the SQLs executed without error, and the attack failed.

But why did we receive an anomaly alert if the attack didn’t break the literal boundary?

Unlike other databases, in MySQL, there are two ways to escape tags in strings. The first is with double tags ('') according to the SQL standard. But there’s a second method of preceding the tag with a backslash (\'). WordPress uses the second method.

That’s where the old version of Core Audit comes into play. That old version was released shortly after the release of MySQL support, and the literal stripping in the Reduced SQL repository did not support the backslash escape method for MySQL databases. As a result, the old version thought the tags were not escaped and didn’t strip the literals correctly.

Once we discovered the unintended consequence of falsely detecting these SQL injection attacks, we purposely kept that old Core Audit version on that website. We wanted to see how many more failed attacks we’ll experience. As stated earlier, this old website experienced nine attempts over the following year. Once we upgraded the Core Audit version, we stopped receiving these false positive anomaly alerts.

Application attack surface area

You might wonder why someone attempted a SQL injection attack that doesn’t work against WordPress. The attackers, like anyone else, had access to WordPress. So why didn’t they know this attack would fail?

That is an interesting question that highlights the complexities of supply chain attacks in some 3rd party applications, like WordPress.

The first thought that comes to mind is that maybe some versions of WordPress are susceptible to this attack. However, SQL injection is a well-known threat, and the WordPress development team is strict about escaping inputs before embedding literals in SQLs. While using bind variables would be safer, web developers have a penchant for embedding literals.

However, it’s worthwhile noting that multiple versions and patches significantly increase the attack surface area. The reason is that most organizations upgrade and patch applications from time to time and can never be sure which vulnerabilities they eliminated or introduced and at what point.

But since it’s unlikely that any WordPress version was susceptible to a SQL injection on the login screen, that brings up another interesting feature of WordPress – Plugins.

A big part of the power and flexibility of WordPress are the tens of thousands of plugins that can extend it. These plugins are code that can attach to various places in WordPress and modify its behavior in almost any way imaginable.

Plugins offer power and flexibility to the users, but they also pose a security risk. WordPress plugins introduce additional vendors, developers, coding standards, changes to the database data model, new execution paths in the application, and, of course, new vulnerabilities.

The risk in plugins is not only vulnerabilities in 3rd party software but also the risk of supply chain attacks. Such attacks could be initiated by the plugin authors or by a hacker who altered their source code.

It’s unlikely that WordPress was ever susceptible to this attack, but it’s highly plausible that some plugin was. The attacker was probably targeting a plugin that was not installed in our WordPress.

Final thoughts

SQL injections are notoriously hard to detect and, even more so, to prevent. However, Core Audit anomaly analysis was able to easily alert on those attacks.

Not only was anomaly analysis able to detect the attack, but it did it without any attack signatures or support for PHP or WordPress. And, actually, without even looking for a SQL injection attack.

And that is the reason anomaly analysis is so effective against SQL injection – it’s not looking specifically for that. It’s searching for SQLs that are new to the application and are, therefore, suspicious. SQL injection can masquerade in many ways but, by definition, is not part of the SQL vocabulary of the application. Anomaly analysis will, therefore, always flag it as suspicious.

WordPress Attack Detection

WordPress Attack Detection

WordPress is a common application for managing websites. But this story is about how we detected an attack on a generic application.

On Sunday morning, we got an anomaly alert. It was March 19, 2023. This story is about what happened.

Background

The Blue Core Research website uses WordPress (a free and open-source content management system). WordPress usually uses MySQL as a backend database, and our installation is no different.

While our WordPress doesn’t contain sensitive data, we still protect its database with Core Audit. We do it both to protect our server and prevent a breach from internet attack, and to use our own software.

As you’ll see in this true story, protecting the database also protects the application. WordPress happens to be the application we protected, but this defense is effective for any application.

The Anomaly

Our Core Audit installation has a relatively simple configuration with daily anomaly detection alerts. We get a few false positives every few days, but on Sunday morning of March 19, 2023, we got an alert of a new error:

Access denied for user ''@'' (using password: YES)

It immediately raised a red flag in my mind. That’s because anomalies only alert of something different, like a change in the application activity profile. But a change that causes an access-denied error seems suspicious.

The Investigation

Core Audit anomalies rely on the Core Audit Security Repository. And this particular anomaly is based on the Reduced SQL portion of that repository. The Reduced SQL repository contains every SQL construct executed in the database at a 5-minute resolution.

Once I got the alert, I logged into Core Audit and looked at the relevant forensic view. I quickly found what I was alerted about:

Date:     Sat 2023/03/18
Time:     18:55 - 19:00
Count:    1 per 5 minutes
Rows:     0
Command:  ERROR TEXT
Activity: Access denied for user ''@'' (using password: YES)

That is an internal MySQL error resulting from a failed login. The user and host in this error are between single quotes (‘) and are, therefore, stripped from the Reduced SQL repository. Striping literals is part of how the Reduced SQL repository operates.

My next stop was to look for the failed session that caused it. Switching to the session forensic view, I found this session:

Start:    2023/03/18 18:55:59
End:      2023/03/18 18:55:59
Type:     No Login
Username: username_here
Machine:  localhost

That seems unusual since we don’t have a user in the database called username_here. That is, obviously, an invalid username. My next stop was to look at the web server logs to see who or what triggered this unusual login.

Here is an excerpt from the Apache log:

[18:55:36] GET /.wp-config.php_copy
[18:55:38] GET /.wp-config.php.rar
[18:55:39] GET /.wp-config.php.7z
[18:55:41] GET /.wp-config.php.tmp
[18:55:42] GET /.wp-config.php_tmp
[18:55:44] GET /.wp-config.php.old
[18:55:46] GET /.wp-config.php.0
[18:55:47] GET /.wp-config.php.1
[18:55:49] GET /.wp-config.php.2
[18:55:50] GET /.wp-config.php.zip
[18:55:52] GET /.wp-config.php.gz
[18:55:53] GET /.wp-config.php~
[18:55:55] GET /wp-config.php.templ
[18:55:56] GET /wp-config.php1
[18:55:58] GET /wp-config.php2
[18:55:59] GET /wp-config-sample.php
[18:56:00] GET /wp-config-backup.txt
[18:56:02] GET /wp-config.php.orig
[18:56:03] GET /wp-config.php.original
[18:56:05] GET /wp-license.php?file=..%2F..
[18:56:06] GET /wp-config.save
[18:56:07] GET /wp-config.txt
[18:56:09] GET /wp-config.dist
[18:56:10] GET /.wp-config.php.swo
[18:56:12] GET /wp-config%20copy.php
[18:56:12] GET /wp-config_good
[18:56:14] GET /wp-config-backup
[18:56:15] GET /wp-config-backup.php
[18:56:16] GET /wp-config-backup1.txt
[18:56:18] GET /wp-config-good
[18:56:19] GET /wp-config-sample.php.bak
[18:56:21] GET /wp-config-sample.php~
[18:56:22] GET /wp-config.backup

The culprit is clearly wp-config-sample.php, and looking inside this PHP file, we can find these lines:

define( 'DB_USER', 'username_here' );
define( 'DB_PASSWORD', 'password_here' );
…
require_once ABSPATH . 'wp-settings.php';

We now understand what happened: someone scanned the website for vulnerabilities and called wp-config-sample.php. That PHP script contains an invalid user and password that triggered a failed connection to the database. Core Audit detected this unusual behavior and raised an alert.

WordPress?

While many won’t consider WordPress a good example of application security, we think it’s valuable because of several important factors:

3rd Party & Supply Chain

First and foremost – WordPress is a 100% third-party application. We didn’t code it, have not reviewed the source code, and have almost no knowledge of the code, the data model, or any other aspect of this application.

Being open-source software, WordPress is exposed to both vulnerabilities hackers may discover in the source code and to supply chain attacks.

To make matters worse, WordPress websites almost always use plugins. Much of the power of the WordPress platform is in its extensibility by the tens of thousands of plugins that are out there. Plugin use significantly expand the surface area of 3rd party software and supply chain attacks. Plugins mean a lot of additional unknown code from multiple vendors or developers, different coding standards, enhancements to the data model with more tables, and more.

In other words – WordPress is what you might consider and extreme example of a 3rd party application and protecting it is more challenging than most other applications.

Dynamic SQL

WordPress takes the concept of dynamic SQL to an extreme. Not only do all the SQLs embed literals, but SQLs are often dynamically generated with where clauses created on the fly based on user input.

The challenge is not only dynamic SQL attacks but also the large SQL vocabulary where it’s impossible to predict all the SQL combinations WordPress may generate.

Again, plugins worsen the problem due to an even larger and unknown SQL vocabulary and more potential vulnerabilities in the code that generates those dynamic SQLs.

Popular & Internet facing

WordPress is very popular and is an internet-facing application. Hackers are, therefore, highly incentivized to find vulnerabilities. Exploiting such vulnerabilities can also be easy since the internet is full of WordPress websites with little or no additional security.

Bottom line – we provided effective defense to a large, dynamic, and extensible application like WordPress without relying on known vulnerabilities or the specifics of the application.

Resolution

Once we knew what the attack was, the next challenge was finding a way to protect the application from this and similar attacks.

In WordPress, the file the was attacked (wp-config-sample.php) is part of the WordPress installation package. The WordPress installation process copies that file into wp-config.php and defines some parameters like the database user and password in the copy.

Therefore, wp-config-sample.php is expected to exist in any WordPress installation. And if the WordPress development team has done its job right, there is probably no means of breaching WordPress by calling it.

The attacker was clearly targeting some vulnerability in the code. And even if that vulnerability doesn’t exist in our installation today, as we all know, bugs exist, and zero-day attacks can always occur. Having that file sitting around seems like asking for trouble. That file serves no purpose in WordPress other than as a template for wp-config.php, so shouldn’t we delete it?

That takes us to another WordPress behavior – the WordPress update. When WordPress updates, it overwrites all the files that are part of the WordPress installation package. Therefore, deleting wp-config-sample.php will be undone as soon as WordPress automatically updates.

Another option is to leave the file in place but change file permissions so that Apache can’t access it. That would prevent that PHP script from executing, but may also cause errors when WordPress attempts to update and overwrite it.

The best solution might be to deny access to it using .htaccess:

<Files ~ "wp-config-sample.php">
deny from all
</Files>

Going Further

As previously explained, wp-config-sample.php is used to create wp-config.php during installation. That means that the copy (wp-config.php) could also be vulnerable to the same attack or other similar zero-day attacks.

More troubling is that if a WordPress update fixes a vulnerability in wp-config-sample.php, that fix will not update in the wp-config.php copy since that copy is never modified.

wp-config.php is meant to be included by other WordPress files like index.php. After defining the database connection parameters, the script calls wp-settings.php to set up the WordPress environment, including a database connection. That’s how we got a connection to the database during the attack.

But wp-config.php is never meant to be called directly. To protect it against direct execution attacks like we saw in this attack, we can add a line at the top of wp-config.php to stop the processing on direct execution:

if (get_included_files()[0] == '/path_to_site/wp-config.php') exit();

Final thoughts

Despite the challenges presented by protecting an application like WordPress, Core Audit anomaly analysis provides effective security. It has a reasonably low false positives level and, in this case, has alerted of an attack against the application.

It’s important to note that Core Audit doesn’t have special support for PHP or WordPress. It doesn’t use signatures and this attack could have been a zero-day vulnerability. Also, our configuration wasn’t looking for any particular vulnerability in the database or the application. We only had a general-purpose anomaly detection that alerted us as soon as the application behaved differently. That was enough to identify the attack.

As you’ve seen, monitoring changes in the database activity profile of the application lets us detect many changes in the application behavior. While some changes occur naturally, others indicate a security problem or an attack.

Risk calculator

Risk Calculator

Estimate the risk of a data breach in your organization. By providing some information specific to your organization you will get an immediate estimate of the risks you are facing.

Risk parameters

How many people are in your organization?
Number of employeesEnter the number of employees in your company. Or, more accurately, the number of people with access to internal company resources such as the network, email, and active directory.
Number of App usersEnter the number of employees who have access to applications with sensitive information. They don’t necessarily need access to the data but to the applications that contain it.
Number of DB usersEnter the number of employees with direct database access, including DBAs. Or, more accurately, the number of individuals whose database accounts will allow an attacker to steal data.
Personnel Risks
Risk of misuse1 in What’s the likelihood an employee will try to steal data? This question relates to human nature and the type of employees in your organization. It’s hard to provide reliable estimates, but statistically, 20% of data breaches are from internal threats. There are also estimates that every year, over 20% of companies experience incidents from intentional employee abuse of privilege. We estimate that 1 in 5,000 is a conservative number.
Risk from social1 in What’s the likelihood an employee will click on the wrong email and compromise their computer? This risk depends on the type of employees and the amount of training they receive. Companies that perform employee training claim to reduce this risk from 60% to 10%. We, therefore, believe that 1 in 10 (10%) is a conservative estimate.
Security Risks & Capabilities
Application Breach%What’s the likelihood that a hacker with access to an application account could steal data? That includes vulnerabilities like SQL injection and the risk the compromised user already has access to the data.
Detect database attacks%How likely are you to know when an individual uses a database account to steal data? You can estimate this based on the number of false positives you regularly get from your detective/alert systems. Not getting false positives means you are unlikely to know when an attack occurs.
Detect application attacks%How likely are you to know when an individual uses an application account to steal data or perform an attack? You can estimate this based on the number of false positives you regularly get from your detective/alert systems. Not getting false positives means you are unlikely to get an alert when an attack occurs.
Risk preview
Database risk
Preview of the total database risk. Click View Results for more details.
Application risk
Preview of the total application risk. Click View Results for more details.

What does it mean?

help

Risk results

Threat from employee misuse
The likelihood that an employee (not a DB or App user) will attempt to steal data.
Threat from employees from social
The likelihood that an employee (not a DB or App user) will fall prey to a social engineering attack.
Threat from user misuse
The likelihood that one of the application users will attempt to steal data.
Threat from users from social
The likelihood that one of the application users will fall prey to a social engineering attack.
Threat to DB from misuse
The likelihood that one of the database users will attempt to steal data.
Threat to DB from social
The likelihood that one of the database users will fall prey to a social engineering attack.
Perimeter breach
The likelihood that an individual inside the network (behind the perimeter) will attempt to steal data due to either misuse or social engineering. To intuitively understand this number, consider the number of employees and the social risk from each one.
Indirect risk
The risk from employees with no application or database access (through misuse or social engineering). This risk is harder to materialize because the attacker must also compromise an application or database account. It’s usually feasible once inside the perimeter but requires an additional step to get to a data breach.
Direct database risk
The likelihood that data will be stolen from the database directly (through misuse or social engineering). It shouldn’t be over 5-10%.
Direct application risk
The likelihood that data will be stolen through the application. (through misuse or social engineering). It shouldn’t be over 5-10%.

Enter your email for a report with customized recommendations:

Contact us with any questions or comments. We’d love to hear from you!

What does it mean?

help

Your database or application risk is over 50%. You’re an easy target waiting to fall prey. There’s a reasonable chance you’ll have a data breach this year or next year if you haven’t already had one you’re unaware of.

Your database or application risk is 20%-50%. There’s a reasonable chance you’ll have a data breach in the next five years because your exposure is statistically high. It’s a question of being targeted or unlucky to fall into the wrong spam campaign rather than your ability to defend.

Your database or application risk is 10%-20%. You have minimal defensive capabilities. There’s a 50/50 chance you’ll have a data breach in the next seven years. Your exposure is moderate, and you’re doing a good job, but you should improve it.

Congratulations! Your database and application risk is lower than 10%, which means you have defensive capabilities and can withstand an attack. If below 5%, you have strong defenses. It doesn’t mean you won’t have a breach, but it’s less likely. Whether from internal abuse or a successful spam campaign, attackers are likely be detected, and your security team can foil the attack.

Graphic designer – Remote

Graphic designer – Remote

Blue Core Research, a software security company based in California, is looking for a full-time graphic designer. This job is remote and requires English as you will work directly with managers and other individuals in the United States on a daily basis.

Responsibilities:

You will be expected to contribute to the creativity and visual aspects of all of our efforts and produce materials for them.
Projects can include, for example:

  • Marketing campaigns
  • Videos
  • Social media posts
  • Advertisements
  • Website

Required skills:

  • Create professional and attractive looking designs including shapes, layouts, colors, etc.
  • Draw and produce materials from scratch
  • Create and edit vector graphics (SVG), for example using illustrator
  • Edit videos
  • Collaborate to create a professional corporate image, and follow that image in your designs.

To apply:

Submit a resume (in English) and a portfolio showing examples of your work to info@bluecoreresearch.com

Database security – self assessment

Database Security – Self Assessment

The following questionnaire will help you evaluate the strength of your database security. It takes about 5 minutes to complete it and at the end you’ll get a score along with an email containing the results with detailed explanations.

Do you know where is your sensitive information? Which database and what tables and columns contain it?
The most elementary requirement to protect sensitive data is to know where it is. Having the list of database that contain it and the tables and columns that require protection is essential.
Have you ensured users only have the minimal privileges they need (least privileged)?
An important best practice is to ensure least privileged – that users only have the permissions needed to perform their job. This is especially important for administrator privileges that are, unfortunately, often granted by mistake or without good justification.
Are you aware of changes in your database?
Change control is a simple way to demonstrate basic control over environments. Since administrators often neglect to document these changes, it is highly recommended to close the loop by monitoring for changes in the environment and approving them.
Do you review who connected to your database?
Knowing what users, programs, and machines connect to the database is the most minimal visibility to understand what’s going on. This information should be reviewed on a daily or weekly basis.
Do you review accesses to sensitive tables?
Special attention must be given to access to sensitive tables. It is important to know who’s performing such access, how much data is accessed, when that access is “unusual”, and more. Establishing effective reporting is essential so the reports are short, meaningful, and easy to review.
Do you monitor DBA activity?
Due to their elevated privileges, DBAs activity is considered a high-risk activity profile. This is both from as an internal threat of abuse of privilege, and in case their credentials are stolen or their machines hacked.
How much time, on average, do you spend on database security?
Effective monitoring can usually be done in less than 2 hours per week. Spending more time suggests your controls are not effective and that you are drowning in useless information. Not spending any time at all, suggests your controls are calibrated so low that you are unlikely to know if a real problem occurred.
Do you monitor for unusual database activity such as users connecting from different programs or from different machines?
Databases have a lot of connections and its easy to miss small changes such as a different IP address for a particular user, or a program that a user doesn’t normally use. Automation can help ensure you are aware of any changes in the connection profiles.
Do you monitor anomalous application activity such as SQL injection?
Applications perform massive amounts of SQLs that are impossible to review individually. This is one place where automation is the only solution. Anomaly analysis, for example, can analyze the activity profile and point out changes in the application behavior. These can be an indication of someone taking advantage of an application flaw to attack the database. SQL Injection is an example of an attack leveraging a common application bug.
How do you audit your database activity?
Auditing database activity requires the right technology. At small scale, home-grow scripts can be effective. However, when auditing more activity of larger databases the performance impact becomes very high and the required time investment – challenging. Using the right solution can help you monitor everything with negligible overhead and achieve effective reporting.
Do you have separation of duties that prevent, for example, DBAs from accessing sensitive data?
Database are designed to have administrator accounts with unlimited privileges. These accounts are a high-risk attack vector both for the internal abuse of privilege threat and in case they are compromised by credential theft or hacking into DBA machines. Reducing the access of these accounts and establishing separation of duties can significantly reduce the risk from DBA accounts.

You finished the self assessment!

Your database security maturity level is out of 10

10 Out of 10

If you’d like to receive a report with your self assessment results and more detailed explanations, please fill in your information:

First name
Last name
Company
Title
Email
Phone

Inside IT Sales – Remote

Inside IT Sales – Remote

Blue Core Research is seeking a hunter with experience in IT software sales for an inside sales position. This position is entirely remote working from anywhere in Latin America.

The ideal candidate will be responsible for the entire sales cycle and for maintaining customer relationships across all of LATAM. This will include identifying and nurturing leads, presenting value propositions, following up, closing, and managing post-sale to ensure customer satisfaction.

Responsibilities:

  • Manage a minimum of 750,000 USD in sales, building a robust pipeline to support it.
  • Provide value proposition to customers and manage the sale cycle from beginning to end.
  • Coordinate negotiations in complex sales cycles with multiple stakeholders and partners, ensuring everyone benefits.
  • Work with marketing on lead generation and nurture those leads to turn them into opportunities all across LATAM.
  • Identify and support channel activities and develop the channel network.

Qualifications:

  • Hunter with an understanding of Databases and Applications
  • Fluent in both English and Spanish (written and verbal skills) as you will work directly with US-based technical and business personnel.
  • Minimum of 2 years experience selling IT security solutions.
  • Able to work throughout the sale cycle from discovery to close.
  • Able to self-generate leads, work alone and with minimum supervision.
  • Experience working with channels
  • Enjoys the challenges of new products and a small company. Technically curious and eager to learn.
  • Preferred experience in sales of solutions for security or databases.

To Apply:

Email info@bluecoreresearch.com with your resume and a cover letter explaining why you think you’d be a good fit for this position.

Presales and Postsales DBA

Presales and Postsales DBA

Blue Core Research is seeking an experienced technical individual for presale and postsale. This position is entirely remote working from anywhere in Latin America.

The ideal candidate will have experience working with sales and customers on technical subjects relating to databases and security. This position supports sales and customers from presale to postsale and support. You must have the ability to present solutions, help sell them, and later implement them in customer production environments. You must be comfortable speaking with customers and able to explain concepts to them, answer questions, demonstrate products, install software, and provide suggestions, best practices, and technical support. Blue Core Research develops advanced technologies for the security and compliance of databases and applications. You must become well-versed in these technologies, related environments, and technical information.

Responsibilities:

  • Senior technical resource across LATAM, working directly with R&D in the United States.
  • Presale – work with sales as a technical resource. Attend meetings, answer questions, do technical presentations, demos, POCs, etc.
  • Postsale – work with paying customers. Do training, knowledge transfers, installations, help in configuration, etc.
  • Support – help customers with 1st and 2nd level support cases.

Qualifications:

  • Fluent Spanish and able to work with management in the USA in English on a daily basis.
  • Minimum 5 years experience working with sales, talking with customers, doing presentations, demos, etc.
  • Minimum 5 years experience working with multiple Databases. At least Oracle, SQL Server, and another database like MySQL or PostgreSQL. Ideally, DBA experience as well as a background in data modeling.
  • Minimum 5 years experience working with multiple Operating systems. At least Linux, Windows, and another Unix like Solaris or AIX.
  • Preferred experience in Security & Compliance. General background in security, compliance, database security, attacks, SQL injection, PCI-DSS, SOX, etc.
  • Preferred experience working with application environments like Java (e.g. tomcat).
  • Preferred experience in Networking. General background in TCP/IP, firewalls, ports, etc.
  • Excellent personal and sales skills, enjoy challenges, can work alone, bright, upbeat, energetic, responsible, and dependable.
  • BS in a technical field or have equivalent work experience.

To Apply:

Email info@bluecoreresearch.com with your resume and a cover letter explaining why you think you’d be a good fit for this position.

Costa Rica Hack

Lessons from the Costa Rica government breach

Introduction

When I first heard the news, my first thought was – how can a hacker group breach so many systems across so many government agencies so quickly? My answer was simple: they cannot. The inevitable conclusion is that they have infiltrated the government systems for months, if not years, waiting for the time they decided to strike.

There must be a systemic problem if someone compromised so many systems across multiple government agencies over a long time. That is not a flaw in one system, a single network, or even one agency – it is a problem across the board. It means there is a fundamental flaw in our security strategy.

Hackers can breach our perimeters and roam inside our systems for a long time, and we’ll have no idea. That is the reality we have just witnessed.

The Problem

That is not the first time we’ve seen hackers infiltrate organizations for months and years. Most large data breaches manifest over a long time.

That is not the first time we’ve seen hackers infiltrate organizations for months and years. Most large data breaches manifest over a long time.

However, we could always find some excuse – they failed to patch this, upgrade that, install an antivirus, etc. There’s always a reason we hang on to, hoping to learn and do better.

But maybe it’s time to accept that the problem is our fundamental approach to security. That the way we do security isn’t working against the existing threats.

Because the simple fact is that the perimeter will always be breached sooner or later, and once the hackers are in – we are clueless. We don’t know they got in, what they’re doing, or how long they’re doing it for.

The Laundry List

The challenge in cybersecurity is that it spans many disparate domains, and we tend to get bogged down by the details of each, losing the view of the bigger picture.

Before looking at methodologies, we should start with a short overview of these different efforts. After all, any strategy will have to include these somehow.

  • Network security – some interpret this differently, but here we mean protecting the corporate network from the internet and isolating internal segments from one another. Network security involves firewalls, routers, VPNs, etc.
  • Endpoint security – relates to desktop and laptop protection. It involves antivirus, anti-malware, and local firewalls. Occasionally, it extends to disk encryption, USB protection, and more. It may also encompass other devices, BYOD, etc.
  • Server security – like endpoints, we must also secure the servers. For Windows servers, this is similar to endpoint security. However, server security extends to a wide range of operating systems such as Linux and other Unix variants. It also focuses more on remote management and the services provided by the servers.
  • Email security – is a significant security problem. It involves email software, spam filters, and various means of protecting the mail system and its users.
  • Vulnerabilities & Patching – known vulnerabilities are often considered a prominent threat. Detecting those and ensuring timely patching helps reduce this exposure.
  • Core IT services – standard services managed by the IT department like the Domain Name System (DNS), the Windows Domain Controller (DC), File servers, and more.
  • Application security – protecting in-house and off-the-shelf applications involves a variety of measures relating to quality control, application features (like authentication, authorization, and auditing), and certain products (like WAF and Core Audit).
  • Database security – protecting databases includes built-in measures (like users & privileges), processes (like change control), and capabilities like activity auditing.
  • Personnel – the Achilles heel of any security strategy. Measures include training, education, and more.
  • Security administration – ensuring we know who everyone is and that they have the correct permissions is a challenge in itself. It usually falls into the realm of Identity Access Management (IAM).
  • Log management – collecting, analyzing, and correlating logs. It is the realm of Security Information Event Management (SIEM).

Security Methodologies

When examining this long laundry list, it’s hard to notice it contains two distinct security methodologies – Perimeter security and Data-centric security.

Data-centric security is a methodology that revolves around the data. Our objective in cybersecurity is to protect the data, and some of the security measures above are aimed directly at doing that. Data-centric security starts with the database where the data is stored, extending outward to the applications that process that data.

Data-centric security includes database security, application security, and IAM. If these security measures are perfect, we will not have a data breach regardless of how many people breach the firewall. Cloud-based applications, for example, rely entirely on these types of measures.

Perimeter security, on the other hand, aims to prevent attackers from getting in. Preventing them from gaining access to internal systems through which they could access the application or the database. A compromised desktop, in itself, is not a data breach. The data breach would occur if the attacker could navigate from that desktop to the database.

Strategically, there are several important attributes when comparing these methodologies:

  • Relevant threats. Perimeter measures are only designed for external threats and are ineffective against internal ones. Threats already inside the perimeter are not addressed. Data-centric security can address both internal and external threats.
  • Effectiveness. Perimeter protections are, usually, statistical defenses – they reduce the number of penetrations but don’t prevent them altogether. No matter how good our spam filters, we still get spam emails. No matter how good our personnel training, people still click on spam emails.
    Data-centric defenses aim to be as close to 100% as possible. It is the last line of defense and aims to be air-tight. A database security measure that prevents 30% of database attacks is considered worthless. The same applies to application security which will only block 40% of the application attacks.
  • Compound effect. Perimeter security is a parallel defense. Attackers only need to breach one of the perimeter measures to get in. If attackers fail to penetrate the firewall they can try the mail system, social engineering, compromising an endpoint, etc.
    Data-centric security is a serial defense. Attackers must penetrate all the layers. An application breach that fails to execute an attack against the database means a failed attack. Accessing the application using a compromised account still means the attacker needs to run the attack through the application and the database.

Landscape Considerations

When building a security strategy, we must consider the threats we perceive as relevant. For example, are we worried about external threats, internal threats, or both? If internal threats are a significant concern, perimeter security will not be effective against those.

We must also consider the effectiveness of different measures in the current landscape. For example, as more and more people work remotely, network security and endpoint security are less effective. Once people work from home, they are outside the corporate firewall and use their home computers. We have minimal ability to control and secure all these remote mini-offices that bypass the perimeter defense through VPN connections.

BYOD (Bring-Your-Own-Device) poses a similar challenge where many uncontrolled and insecure phones and tablets roam the corporate network.

As the modern landscape changes and the effectiveness of perimeter controls diminishes, there’s a growing need to shift the focus to internal defenses. As part of this shift, there’s a redefinition of the perimeter line – protecting the data center network is becoming as important, if not more, than the corporate network.

Layered Security

Security isn’t always about the weakest link. This soundbite is somewhat true when talking about perimeter defenses deployed in parallel. Attackers that are equally talented at all forms of attack are likely to attack through the weakest link. In this case, the priority is reinforcing the weak link.

However, data-centric defenses deployed in serial can reinforce one another. For example, exploiting a compromised application account could be detected through application auditing or database auditing.

In addition, data-centric measures are always in serial to perimeter defenses and will reinforce weak links in them. No perimeter breach can manifest into a data breach without compromising the internal data management systems.

A strategic layering of defenses can force attacks through many barriers providing powerful protection. Implementation is simple – follow possible attack scenarios and ensure you have different measures at various points along each path.

For example, data-centric philosophy says all attacks must, eventually, penetrate the database. Database protection is, therefore, a high priority, and will reinforce all other defenses.

IDS and IPS

IPS (Intrusion Prevention Systems) aims to prevent attacks and breaches. These are classic security measures like firewalls and passwords.

IDS (Intrusion Detection Systems) aim to detect attacks and report or alert about them. These include measures like auditing and SIEM.

Compared to physical bank security, IPS is like the vault door, while IDS is the alarm system, motion sensors, etc.

For example, we know our IPS systems are under constant attack, but we are never informed about attacks that go through. an IDS informs security personnel of the attack allowing them to respond in different ways. Responses can include taking systems offline, diverting attacks to honeypots, tracing the attack back to its source, and more. In all cases, attackers don’t get a second chance to try and breach the same defense again. IDS systems are, therefore, much harder for attackers to circumvent.

Generally speaking, while IPS could prevent an intrusion, IDS is more likely to detect it and less likely to be circumvented. Therefore, whenever possible, it is always recommended to deploy both types of systems. IPS to block most attacks and IDS to detect the ones that go through.

Strategically, there are important differences between IPS and IDS that are vital to remember:

  • Tolerance to false positives. False positives in IPS mean the system prevents users from performing legitimate activities. Therefore, IPS cannot tolerate false positives.
    False positives in IDS mean more reports or alerts that require investigation by security personnel. While we don’t want too many false positives in reports and alerts, IDS are designed and calibrated to have a certain amount of those.
    Since it’s impossible to perfectly calibrate a security system, zero false positives mean some attacks go through (a false negative).
  • Response time. IPS must determine whether activities are valid before letting them through. A slow IPS system means a slow response to the protected IT system and users that complain. IPS are, therefore, designed to use real-time algorithms capable of making instant judgment calls.
    IDS, on the other hand, can take their time to report or alert. IDS tends to employ more complex algorithms and can analyze large volumes of data to identify intrusions. They can refer to historical information as well as wait for future events to occur and correlate.
  • Circumvention. When an IPS system prevents an attack, the attacker is, inevitably, aware of the failed attempt and can try again. IPS are, therefore, constantly challenged until being successfully circumvented.
    IDS systems don’t inform the attacker and are, therefore, much more difficult to circumvent.

Compensating Activities

When securing a bank vault, you could deploy motion sensors, laser beams, heat sensors, and more. Each type of security measure adds protection and compensates for the limitations of another.

The same principle applies to IT security – doing different activities will increase the likelihood of detecting and stopping a breach.

For example, consider these types of IDS-related activities:

  • Declarative auditing. In this form of security monitoring, the security team defines the activity it wishes to monitor. These are usually activities that are high-risk and low-volume.
  • Anomaly analysis. In this form of security monitoring, automation built into the security system attempts to detect unusual activity.
  • Proactive forensics. In this form of security monitoring, the security team uses tools to investigate and analyze all the activity in the system. The objective is to detect malicious behavior, poor practices, design security controls, and more.

Security Strategy

Finally, we need to design the overall security strategy and determine how to allocate our budget and personnel.

A strategy that maximizes the return on investment and minimizes the chances of a breach should include:

  • Balanced methodologies. Balance the strength of perimeter and data-centric defenses. We tend to over-emphasize the importance of perimeter security. The result is that any perimeter breach ends up with a data breach. Perimeter breaches are inevitable and without a solid data-centric posture, we are merely waiting for the breach to occur.
  • Balanced perimeter. Balance the strength of the various perimeter measures relative to the risk. A good firewall with no antivirus or spam filter is usually not the best investment unless personnel poses a low risk compared with a network breach.
  • Layered security. We cannot overstate the importance of implementing multiple Data-Centric defense layers. It is one of the most effective yet disregarded areas in cybersecurity.
  • IPS and IDS. Deploy both IPS and IDS whenever possible. It is vital to know when an IPS is breached and a good IDS is the only way that can happen. It is also a way of adding additional security layers as separate IPS and IDS create two sequential protection barriers.
  • Compensating activities. Create as many independent types of activities within each security layer. Different kinds of activities tend to compensate for one another and provide better visibility into what’s going on inside your IT systems.

Final thoughts

Ultimately, security is about visibility. Lack of visibility is how attackers get into your IT systems and roam around for months and years without being detected.

If you don’t feel you know who’s accessing your systems and what’s happening inside them – you are not secured.

Adding multiple protections across multiple systems in a data-centric fashion is also an excellent way to increase visibility into any potential data breach.

But remember that visibility means that security personnel is actively looking at and understanding what’s going on. That means people, time, and appropriate skills. Security done by machines alone is always limited and will be breached sooner rather than later.

Cybersecurity is about constantly improving since we can always do better. Following these concepts to structure a balanced and versatile security strategy will facilitate efficient use of resources while improving your overall security posture. That’s how we can lower the risk of a data breach.

Based in Aliso Viejo, California, Blue Core Research provides advanced security and compliance solutions for databases and applications.

To learn more about data-centric security in general or our solutions in particular, contact us at marketing@bluecoreresearch.com