Tag: security

What’s the Most Powerful Tool in Your Security Arsenal? 

Posted on by eugene evdokimov

Trying to work out the best security tool is a little like trying to choose a golf club three shots ahead – you don’t know what will help you get to the green until you’re in the rough.

Traditionally, when people think about security tools, firewalls, IAM and permissions, encryption, and certificates come to mind. These tools all have one thing in common – they’re static. In this piece, we’re going to examine the security tools landscape and understand which tool you should be investing in.

Security Tools – The Lay of the Land

The options available today to the discerning security-focused organization are diverse. From start-ups to established enterprises, understanding who makes the best firewalls or who has the best OWASP top ten scanning is a nightmare. We’re not here to compare vendors, but more to evaluate the major tools’ importance in your repertoire.

Firewalls and Intrusion Detection Systems

Firewalls are a must-have for any organization, no one is arguing there. Large or small, containerized or monolithic, without a firewall you’re in big trouble.

Once you’ve selected and configured your firewall, ensuring it gives the protection you need, you might think you’ve uncovered a silver bullet. The reality is that you have to stay on top of some key parameters to make sure you’re maximizing the protection of the firewall or IDS. Monitoring outputs such as traffic, bandwidth, and sessions are all critical to understanding the health and effectiveness of your firewalls.

Permissions Tooling

The concept of Identity and Access Management has evolved significantly in the last decade or so, particularly with the rise of the cloud. The correct provisioning of roles, users, and groups for the purposes of access management is paramount for keeping your environment secure.

Staying on top of the provisioning of these accesses is where things can get a bit difficult. The ability to understand (through a service such as AWS Cloudwatch) all of the permissions assigned to individuals, applications, and functions alike is difficult to keep track of. While public CSPs have made this simpler to keep track of, the ability to view permissions in the context of what’s going on in your system gives enhanced security and confidence.

Encryption Tooling

Now more than ever, encryption is at the forefront of any security-conscious individual’s mind. Imperative for protecting both data at rest and in flight, encryption is a key security tool. 

Once implemented, you need to keep track of your encryption, ensuring that it remains in place for whatever you’re trying to protect. Be it disk encryption or encrypted traffic on your network, it needs to be subject to thorough monitoring.

Monitoring is the Foundation

With all of the tool types that we’ve covered, there is a clear and consistent theme. Not only do all of the above tools have to be provisioned, they also rely on strong and dependable monitoring to assist proactive security and automation.

Security Incident Event Management

The ability to have a holistic view of all of your applications and systems is key. Not only is it imperative to see the health of your network, but if part of your application stack is underperforming it can be either symptomatic of, or inviting to, malicious activity.

SIEM dashboards are a vital security tool which use the concept of data fusion to provide advanced modelling and provide context to otherwise isolated metrics. Using advanced monitoring and altering, the best SIEM products will not only dashboard your system health and events in realtime, but also retain log data for a period of time to provide event timeline reconstruction.

The Power of Observability

Observability is the new thing in monitoring. It expands beyond merely providing awareness of system health and security status to giving cross-organizational insights which drive real business outcomes.

What does this mean for our security tooling? Well, observability practises drive relevant insights to the individuals most empowered to act on them. In the instance of system downtime, this would be your SREs. In the case of an application vulnerability, this would be your DevSecOps ninjas. 

An observability solution working in real time will not only provide telemetry on the health and effectiveness of your security tool arsenal, but will also give real-time threat detection. 

Coralogix Cloud Security

Even if you aren’t certain which firewall or encryption type comes out on top, you can be certain of Coralogix’s cloud security solution.

With a quick, 3-step setup and out-of-the-box functionality including real-time monitoring, you can be sure that your tools and engineers can react in a timely manner to any emerging threats. 

Easily connect any data source to complete your security observability, including Audit logs, Cloudtrail, GuardDuty or any other source. Monitor your security data in one of 100+ pre-built dashboards or easily build your own using our variety of visualization tools and APIs.

DevSecOps vs DevOps: What are the Differences?

Posted on by eugene evdokimov

The modern technology landscape is ever-changing, with an increasing focus on methodologies and practices. Recently we’re seeing a clash between two of the newer and most popular players: DevOps vs DevSecOps. With new methodologies come new mindsets, approaches, and a change in how organizations run. 

What’s key for you to know, however, is, are they different? If so, how are they different? And, perhaps most importantly, what does this mean for you and your development team?

In this piece, we’ll examine the two methodologies and quantify their impact on your engineers.

DevOps: Head in the Clouds

DevOps, the synergizing of Development and Operations, has been around for a few years. Adoption of DevOps principles has been common across organizations large and small, with elite performance through DevOps practices up 20%.

The technology industry is rife with buzzwords, and saying that you ‘do DevOps’ is not enough. It’s key to truly understand the principles of DevOps.

The Principles of DevOps

Development + Operations = DevOps. 

There are widely accepted core principles to ensure a successful DevOps practice. In short, these are: fast and incremental releases, automation (the big one), pipeline building, continuous integration, continuous delivery, continuous monitoring, sharing feedback, version control, and collaboration. 

If we remove the “soft” principles, we’re left with some central themes. Namely, speed and continuity achieved by automation and monitoring. Many DevOps transformation projects have failed because of poor collaboration or feedback sharing. If your team can’t automate everything and monitor effectively, it ain’t DevOps. 

The Pitfalls of DevOps

As above, having the right people with the right hard and soft skills are key for DevOps success. Many organizations have made the mistake of simply rebadging a department, or sending all of their developers on an AWS course and all their infrastructure engineers on a Java course. This doesn’t work – colocation and constant communication (either in person, via Slack or Trello) are the first enablers in breaking down silos and enabling collaboration. 

Not only will this help your staff cross-pollinate their expertise, saving on your training budget, but it enables the organic and seamless workflow. No two organizations or tech teams are the same, so no “one size fits all” approach can be successfully applied.

DevSecOps: The New Kid On The Block

Some people will tell you that they have been doing DevSecOps for years, and they might be telling the truth. However, DevSecOps as a formal and recognized doctrine is still in its relative infancy. If DevOps is the merging of Development and Operations, then DevSecOps is the meeting of Development, Security, and Operations. 

Like we saw with DevOps adoption, it’s not just as simple as sending all your DevOps engineers on a security course. DevSecOps is more about the knowledge exchange between DevOps and Security, and how Security can permeate the DevOps process. 

When executed properly, the “Sec” shouldn’t be an additional consideration, because it is part of each and every aspect of the pipeline.

What’s all the fuss with DevSecOps?

The industry is trending towards DevSecOps, as security dominates the agenda of every board meeting of every big business. With the average cost of a data breach at $3.86 million, it’s no wonder that organizations are looking for ways to incorporate security at every level of their technology stack.

You might integrate OWASP vulnerability scanning into your build tools, use Istio for application and container-level security and alerting, or just enforce the use of Infrastructure as Code across the board to stamp out human error.

However, DevSecOps isn’t just about baking Security into the DevOps process. By shifting security left in the process, you can avoid compliance hurdles at the end of the pipeline. This ultimately allows you to ship faster. You also minimize the amount of rapid patching you have to do post-release, because your software is secure by design.

As pointed out earlier, DevOps is already a successful methodology. Is it too much of a leap to enhance this already intimidating concept with security as well? 

DevOps vs DevSecOps: The Gloves Are Off

What is the difference between DevOps and DevSecOps? The simple truth is that in the battle royale of DevOps vs DevSecOps, the latter, newer, more secure contender wins. Not only does it make security more policy-driven, more agile, and more enveloping, it also bridges organizational silos that are harmful to your overall SDLC.

The key to getting DevSecOps right lies in two simple principles – automate everything and have omnipotent monitoring and alerting. The reason for this is simple – automation works well when it’s well-constructed, but it still relies on a trigger or preceding action to prompt that next function. 

Every single one of TechBeacon’s 6 DevSecOps best practices relies on solid monitoring and alerting – doesn’t that say a lot?

Coralogix: Who You Want In Your Corner

Engineered to support DevSecOps best practices, Coralogix is the ideal partner for helping you put security at the center of everything. 

Alerts API allows you to feed ML-driven DevOps alerts straight into your workflows, enabling you to automate more efficient responses and even detect nefarious activity faster. Easy to query log data combined with automated benchmark reports ensure you’re always on top of your system health. Automated Threat Detection turns your web logs into part of your security stack. 

With battle-tested software and a team of experts servicing some of the largest companies in the world, you can rely on Coralogix to keep your guard up.

Best Practices for Writing Secure Java Code

Posted on by eugene evdokimov

Every Java developer should follow coding standards and best practices to develop secure Java code. It is critical your code is not vulnerable to exploits or malicious attacks. In recent times, even big organizations like eBay, the CIA, and the IRS have fallen victim to vulnerabilities in their applications that have been discovered and exploited by attackers. 

The following guidelines provide a solid foundation for writing secure Java code and applications. These will minimize the possibility of creating security vulnerabilities caused by Java developers and help prevent known malicious attacks. 

1. Only Use Tried and Tested Libraries 

A large percentage of the code in applications is sourced from public libraries and frameworks. These libraries can contain vulnerabilities that may allow a malicious attacker to exploit your application. 

Organizations trust their business and reputation to the libraries they use, so make sure you only use proven ones and keep them up to date with the latest versions. Consider checking if they have any known vulnerabilities or require any security fixes.

2. Avoid Serialization

Java serialization is inherently insecure which is why Oracle recently announced it has a long-term plan to remove it. Serialization vulnerabilities were recently found in Cisco and Jenkins applications. 

Any application that accepts serialized Java objects is vulnerable, even if a library or framework is responsible and not your own Java code. One area to watch out for is making an interface serializable without thinking through what could be exposed. Another pitfall to avoid is accidentally making a security-sensitive class serializable, either by subclassing or implementing a serializable interface.

3. Always Hash User Passwords

Never store any passwords as plain text. Always hash user passwords preferably using a salted hash and a recommended hashing algorithm like SHA-2. When a password has been ‘hashed’, it has been turned into a scrambled version of itself. Using a predefined key known to the application, the hash value is derived from a combination of both the password and the key using a hashing algorithm.

4. Filter Sensitive Information From Exceptions

Exception objects can contain sensitive information that can assist an attacker hoping to exploit your system. An attacker can manufacture input arguments to expose internal structures and mechanisms of the application. It’s important to remember that information can be leaked from the exception message text and the type of an exception.

Take for example the FileNotFoundException message. These messages contain information about the layout of the file system and the exception type reveals the missing requested file. 

To secure Java code applications, you should filter both exception messages and exception type.

5. Do Not Log Sensitive Information

Data thefts cause massive harm to individuals and organizations, and developers need to do everything possible to prevent them from happening. Information like credit and debit card numbers, bank account numbers, passport numbers, and passwords are highly sensitive and valuable to criminals. Don’t store this type of information in log files and make sure it’s not detectable through searches in cleartext. 

If you have to log any sensitive information like card numbers, for example, think about logging only part of the card number e.g. the last four digits, and make sure it’s encrypted using a proven library. Don’t write your own encryption functionality. 

6. Error Handling and Logging 

You can accidentally reveal sensitive information in user error messages and error messages recorded in the log files, such as account information or system details. 

A safer way is to use generic screen error messages for users. Additionally, write log error messages that will help support teams investigating production issues without providing an attacker with useful information to further exploit your systems.

7. Write Simple Java Code

Generally speaking, simple java code is secure java code. Here are some tips on keeping your code simple and secure:

  • Keep it as simple as possible without reducing functionality. 
  • Use code quality checking products like SonarQube. This tool will continuously inspect the code quality whilst checking for any new vulnerabilities in your latest code release. Once a bug or vulnerability is in production, it is a lot harder to fix it compared to the effort to prevent it in the first place. 
  • Expose the minimum amount of information in your code. Hiding implementation details is good for keeping your code both secure and maintainable. 
  • Make good use of Java’s access modifiers. Declare the most restrictive access levels for classes, methods, and their attributes possible. Set everything that can be set to private, as private. 
  • Always define the smallest possible API and interface objects. Decouple components and make them interact in the smallest scope possible. If one component of your application is compromised by a breach, the others will be safe.

8. Prevent Injection Attacks

An injection attack occurs when malicious code is injected into the network. This type of attack is considered a major problem in web application security and is listed as the number one security risk in the OWASP Top 10. Any application that allows users to enter or upload data might contain a vulnerability that can allow an injection attack. Insufficient user input validation is usually the primary reason injection vulnerabilities exist. 

SQL Injection 

SQL Injection vulnerabilities are created when developers write dynamic database queries that can include user input. An attacker can include SQL commands in the input data, in any screen input field. Then because of a vulnerability in the code, the application runs the rogue SQL in the database. This gives attackers a way to bypass the application’s authentication functionality and allow them to retrieve the contents of an entire database. 

Key things to remember to prevent SQL injections: 

  • Never build SQL statements by concatenating arguments. This allows a high probability of SQL injection attacks.
  • Avoid dynamic SQL. Use Prepared Statements (with parameterized queries). 
  • Use stored procedures. 
  • Whitelist input validation. 
  • Escape user-supplied input. 

XPath Injection 

XPath injections are similar to SQL injections in that they can attack websites that operate on user-supplied information to construct an XPath query for XML data. An attacker can gain detailed information on how the XML data is structured or access data that is not normally accessible by sending malicious information to the website. 

These vulnerabilities can also elevate the attacker’s privileges in the application if the XML data is being used for authentication. 

You can avoid XPath injection by similar techniques used to prevent SQL injection: 

  • Sanitize all user input. 
  • When sanitizing, verify the data type, format, length, and content. 
  • In client-server applications, perform validation at both the client and the server sides.
  • Thoroughly test applications especially user input. 

Cross-Site Scripting 

Cross-Site Scripting (XSS) attacks happen when an attacker uses a web application to send malicious code (usually a browser-side script) to other users. Vulnerabilities that allow these attacks can occur anywhere a web application receives input from a user, within the output it generates, without validating or encoding it. 

To keep Java code applications secure and prevent XSS, filter your inputs with a whitelist of allowed characters and use a proven library to HTML encode your output for HTML contexts. For JavaScript use JavaScript Unicode escapes. 

Summary 

In summation, there are some key points to bear in mind in writing secure Java code. You should always think about security in the development of your application in the design stage and code reviews, as well as look for vulnerabilities in your Java code and take advantage of the Java security APIs and libraries.

Only ever use highly rated vendor tools to monitor and log your code for security issues. This means you should investigate the full list of application attack types and follow the recommended prevention methods.

If you use these guidelines for writing secure Java code applications in your organization, you can protect yourself and your applications against malicious attacks and data theft.

Network Security: The Journey from Chewiness to Zero Trust Networking

Posted on by eugene evdokimov

Network security has changed a lot over the years, it had to. From wide open infrastructures to tightly controlled environments, the standard practices of network security have grown more and more sophisticated.

This post will take us back in time to look at the journey that a typical network has been on over the past 15+ years. From a wide open, “chewy” network, all the way to zero trust networking.

Let’s get started.

Network Security in the Beginning…

Let’s say we work at a company that’s running a simple three-tiered web architecture. We have a frontend service, a backend service, and a database. It’s 2005, and we run each of our services and the database on a separate machine.

trusted network

The Problem? Our Network is Wide Open to Attack

An attacker gaining any sort of access to our network will be able to move throughout the entire network, exfiltrating data and causing havoc. Basically, our network is wide open to attack. Luckily for us, the fix is quite straightforward. At least, for now.

So, We Introduce Network Segmentation

Word reaches us about the new and improved security best practices, and we segment our network based on the “least privilege” principle. 

The Principle of Least Privilege

The principle of “least privilege” has become a staple of security thinking over the years. Its arguments are common sense. A service should have only the permissions that it needs to complete its function and nothing more. This sounds obvious, but from an engineering perspective, it is often easier to give something wide powers. This helps to avoid the need to revisit application permissions for every new feature change. 

From a networking perspective, the principle of least privilege argues that each server should only have the permissions and network access that it needs to run. Simple, right?

Applying the Principle of Least Privilege to our Network Security

least privilege security

We split each of our servers into its own network. This router makes sure that services can only communicate with their appropriate databases. This is important. It means that if an attacker manages to compromise one of the backend segments, they can not laterally move to the other segments. They can only visit the nodes that we have allowed. This limits the blast radius of an attack and makes for a much more difficult system to hack.

The Problem? Scale!

If we need to add any servers, or run additional services on these servers, the number of rules grows very quickly, as each rule needs to be duplicated by the number of machines. This poses a bit of an issue for us, but as long as the server count remains low, we should be alright. 

Unfortunately, over the past few years, architectural patterns like microservices have massively increased the number of virtual machines that we use. This increase makes this model far less viable, but we’ll get to that.

Moving to the Cloud

Our company, being savvy and technologically forward-thinking, decides to move to an early cloud offering. 

moving to the cloud

So far, so good! We’ve taken the lessons of our physical network segmentation and applied them here. Our instances are segmented from each other using security groups, which are basically firewall rules enforced by a virtual appliance. 

Our new infrastructure enables our company to handle more traffic and, ultimately, make more money. Soon, however, even our shiny cloud infrastructure needs some work. 

Introducing the Cluster

To deal with scale, our company containerizes its services. The services move to a managed Kubernetes cluster, and the database moves to a managed cloud database. 

cluster architecture

Very clean and elegant! (Yes, it’s oversimplified, but bear with me). Our services are now managed and leveraging auto-scale. 

The Problem? Still, Scale…

Our previous network setup relied on some pretty basic assumptions. We had a “Database server” and that server would host our database. We had a “Backend Server” and we could rely, 100% of the time, on our backend server hosting our backend application.

Now, however, there are no dedicated server roles. We find ourselves in a completely different paradigm. Our servers are simply agnostic hosts of docker containers and don’t know a great deal about the internals of these containers. So how do we set up rules to ensure a principle of least privilege?

The Solution? An Entirely New Approach

Before, we were thinking about servers in terms of their networking identity. For example, an IP address. This was adequate, but there is no longer a consistent mapping between IP address and service. We need to stop identifying services by some proxy variable, such as IP, and start identifying services directly. How do we do that, and how do we manage relationships between these identities?

service mesh

The Service Mesh

A service mesh is a relatively new entry into the networking scene. It operates at a much higher level than traditional networking does. Rather than worrying about the underlying switches, routes and such, it registers itself with each application in your system and processes rules about application to application communication. The service mesh has some specific differences from a traditional set up that must be understood.

Intention-Based Security

Intention-based security refers to a style of declaring security rules. Rather than having obscure networking rules that directly configure underlying switches, we declare the intention of each service, at the service level. For example, Service A wishes to communicate with Service B. 

This abstracts the underlying server and means that we no longer have to rely on assumptions about IP addresses. We can declare our intentions directly.

The Mesh Proxy (Sometimes Called Sidecar)

The service mesh is made up of a control plane and a network of proxies. The control plane configures the proxies, based on the intentions declared by the user. The proxies then intercept all traffic moving in and out of the service and, if the rules apply, will transform, reroute or block the traffic entirely. This network of proxies makes up the service mesh.

The Problem? Risk of System Disruptions

The most obvious drawback of this architecture is that there are many, many proxies. At least one per service. This means that a single broken proxy can disrupt all traffic for a service. We need to be able to monitor the health and configuration for each of these proxies, otherwise we will quickly lose the ability to track down problems.

The Solution? A Powerful Observability Platform

Observability is the answer here. You need a powerful platform, through which you can interrogate your infrastructure. You can find out about memory, CPU and networking status of your proxies and services, and ensure that your entire service mesh is running optimally.

Coralogix provides world class observability and regularly processes over 500,000 events, every second. If you need to level up your insights and gain new control over your system, check out how we can help.

Our Journey

We began with simple networking rules that blocked traffic from server to server. As we can see, the arms race between security and sophisticated software techniques continues. We have arrived at a point where we can directly declare services, by their human readable names, and control traffic through a network of distributed proxies.

Wherever you find yourself on this journey, the most exciting thing is that there is always somewhere new to go!

Stop Enforcing Security Standards – Start Implementing Policies

Posted on by eugene evdokimov

In days gone by, highly regulated industries like pharmaceuticals and finance were the biggest targets for nefarious cyber actors, due to the financial resources at banks and drug companies’ disposal – their respective security standards were indicative of this. Verizon reports in 2020 that, whilst banks and pharma companies account for 25% of major data breaches, big tech, and supply chain are increasingly at risk. 

Surely then, the way to protect against vulnerabilities and nefarious activities is to rigorously enforce security standards? Wrong.

In this piece we’re going to examine the landscape of information security policies today, and how new approaches and tools make security seamless.

Security Standards – As They Were

Security standards come in all shapes and sizes, some are relevant to developers, whilst some are more relevant to how a whole organization holds and handles data. Traditionally, security standards are enforced by an individual – typically an infosec or compliance persona. This approach has two flaws – the enforcer’s distance from the developers, and the broad strokes of infosec standards.

The Problem With the Old Way

Under this model, and particularly in big companies, information security and compliance is governed by separate teams or individuals. These people are normally non-technical and are logically separated from the development team. This means that the enforcers of security standards don’t always understand the implications of what they are enforcing, nor the people upon who they are imposing the standards.

Additionally, recent research has shown that the security standards that we all know are applied like blankets from industry to industry. With no specificity for development methodology, organizational resource, or data being handled, these overarching principles don’t engage the developers that should be adhering to them. 

All this comes down to a reliance on people, be it compliance professionals or developers, to understand, enforce, and implement these policies. This is not only a manual task, but it’s also onerous and doesn’t embrace the models of successful agile product development and release.

DevSecOps – A New Way

If you’re familiar with Disney’s The Mandalorian, then you’ll know the unending mantra of “this is the way”, uttered by all members of the secret sect. DevSecOps has shown the technology industry that dictated standards aren’t the only way.

A shift-left mentality, DevSecOps requires organizations to bridge the gap (and in some cases, absorb the space) between development and security. An article on the rise and success of DevSecOps outlined three defining criteria of a true DevSecOps environment. First, developers should be in charge of security testing. Second, fixing security issues should be wholly managed by the development team. Third, ongoing security-related issues should be owned by the development team. 

Simple enough, right? 

Whilst the principles for DevSecOps success are straightforward, the practices are often less so. Creating a secure-by-design architecture and coding security elements into your applications are key ways of breaking down the silos that security standards created.

Security and Development – How to Promote Cohesion

Gartner states that cultural and organizational roadblocks are the largest impeders to the unification of development and security operations individuals and teams. Looking at research from Gartner, surveyed CIOs and leading software vendors, security should be wrapped around DevOps practices, not just shoved into the mix.

From Principle to Practice to Policy

What does wrapping security around DevOps mean? In theory, it’s allowing the expertise of SecOps engineers and compliance professionals to impact development. In practice, it means allowing these professionals’ knowledge of the changing security and threat landscape to permeate in day-to-day DevOps activities.

Take Kubernetes for example. It provides network policies, which under the traditional model, may be allocated as part of an overarching InfoSec strategy. Neither dynamic nor totally secure, this is setting yourself up for failure. Implementing Zero Trust Networking is a DevSecOps mindset which, with tools like Istio, gives a service mesh providing both application and container-level security through alerting policies and active prevention. 

Alerting Makes DevSecOps Easy

Alerting is key. It takes away the idea of rigid security standards and instead provides the flexibility of implementable policies throughout the application and network layers. In an article covering the DevSecOps keys to success, there is one recurring theme – use whatever tools at your disposal to increase process speed. A mature monitoring and alerting system is the lynchpin to rapid security and development practices and provides the foundation for automation.

By integrating monitoring and alerting capabilities into a SIEM dashboard, security events can be analyzed in a cross-cutting way to tie together many extraneous factors which would otherwise be disparate. Adding automation, even something as simple as advanced messaging, on top shortens response time and guarantees uptime. When so much of DevSecOps is reliability engineering, your monitoring and alerting tool is the quarterback in your stack.

Coralogix is the Platform for Your New DevSecOps Culture

Out-of-the-box fully wrapped SaaS monitoring and altering with built-in threat detection – “this is the way”.

Coralogix provides policy-based analysis to support your monitoring. On top of that, you get alerting with myriad integrations to plug into every component of your stack. This alerting allows for sophisticated policy creation based on security requirements, empowering a true DevSecOps mentality and workflow within your organization. 

Features like Flow Anomaly, ML-powered Dynamic Alerts, and a simple Alerts API mean you no longer need rigid security standards. Intelligent, inbuilt policies guarantee your applications and infrastructure can stay protected and progressive.

5 Common Elasticsearch Mistakes That Lead to Data Breaches

Posted on by eugene evdokimov

Avon and Family Tree aren’t companies you would normally associate with cybersecurity, but this year, all three were on the wrong side of it when they suffered massive data breaches. At Avon 19 million records were leaked, and Family Tree had 25GB of data compromised. What do they have in common? All of them were using Elasticsearch databases.

These are just the latest in a string of high profile breaches that have made Elasticsearch notorious in cybersecurity.  Bob Diachenko is a cybersecurity researcher. Since 2015, he’s been investigating vulnerabilities in NoSQL databases. 

He’s uncovered several high profile cybersec lapses including 250 million exposed Microsoft records. Diachenko’s research suggests that 60% of NoSQL data breaches are with Elasticsearch databases. In this article, I’ll go through five common causes for data breaches and show how the latest Elastic Stack releases can actually help you avoid them.

1. Always Secure Your Default Configuration Before Deploying

According to Bob Diachenko, many data breaches are caused by developers forgetting to add security to the default config settings before the database goes into production. To make things easier for beginner devs, Elasticsearch traditionally doesn’t include security features like authentication in its default configuration. This means that when you set up a database for development, it’s accessible to anyone who knows the IP address.

Avoid Sitting Ducks

The trouble starts as soon as a developer pushes an Elasticsearch database to the internet. Without proper security implementation, the database is a sitting duck for cyberattacks and data leaks. Cybersecurity professionals can use search engines like Shodan to scan for open IP ports indicating the presence of unsecured Elasticsearch databases. As can hackers. Once a hacker finds such a database, they can freely access and modify all the data it contains.

Developers who set up Elasticsearch databases are responsible for implementing a secure configuration before the database goes into production. Elasticsearch’s official website has plenty of documentation for how to secure your configuration and developers need to read it thoroughly.

Elasticsearch to the Rescue

That being said, let’s not put all the blame on lazy programmers! Elasticsearch acknowledges that the fast-changing cybersecurity landscape means devs need to take their documentation with a pinch of salt. Users are warned not to read old blogs as their advice is now considered dangerous. In addition, Elasticsearch security can be difficult to implement. Developers under pressure to cut times to market won’t necessarily be incentivised to spend an extra few days double checking security.

To combat the threat of unsecured databases, Elasticsearch have taken steps to encourage secure implementation as a first choice. Elastic Stack 6.8 and 7.1 releases come with features such as TLS encryption and Authentication baked into the free tier. This should hopefully encourage “community” users to start focussing on security without worrying about bills. 

2. Always Authenticate

In 2018, security expert Sebastien Kaul found an Elasticsearch database containing tens of millions of text messages, along with password information. In 2019, Bob Diachenko found an Elasticsearch database with over 24 million sensitive financial documents. Shockingly, neither database was password protected.

So why are so many devs spinning up unauthenticated Elasticsearch databases? On the internet! In the past, the default configuration didn’t include authentication. Devs used the default configuration because it was convenient and free.

To rub salt on the wound, Elasticsearch told users to implement authentication by placing a Nginx server between the client and the cluster. This approach had the downside that many programmers found setting up the correct configuration much too difficult for them.

Recognising the previous difficulties, Elasticsearch has recently upgraded the free configuration. It now includes native and file authentication. The authentication takes the form of role based access control. 

Elasticsearch developers can use Kibana to create users with custom roles demarcating their access rights.  This tutorial illustrates how role based access control can be used to create users with different access rights.

3. Don’t Store Data as Plain Text

In his research, Bob Dianchenko found that Microsoft had left 250 million tech support logs exposed to the internet. He discovered personal information such as emails had been stored in plain text.  

In 2018, Sebastien Kaul found an exposed database containing millions of text messages containing plain text passwords.

Both of these are comparatively benign compared to Dianchenko’s most recent find, a leaked database containing 1 billion plain text passwords. With no authentication protecting it, this data was ripe for hackers to plunder. Access to passwords would allow them to commit all kinds of fraud, including identity theft.

Even though storing passwords in plain text is seriously bad practice, many companies have been caught doing it red handed. This article explains the reasons why.

Cybersecurity is No Laughing Matter

In a shocking 2018 twitter exchange, a well-known mobile company admitted to storing customer passwords in plain text. They justified this by claiming that their customer service reps needed to see the first few letters of a password for confirmation purposes.

When challenged on the security risks of this practice, the company rep gave a response shocking for its flippancy.

“What if this doesn’t happen because our security is amazingly good?”

Yes, in a fit of poetic justice, this company later experienced a major data breach.  Thankfully, such a cavalier attitude to cybersecurity risks is on the wane.  Companies are becoming more security conscious and making an honest attempt to implement security best practice early in the development process. 

Legacy Practices

A well-known internet search engine stored some of it’s account passwords in plain text. When found out, they claimed the practice was a remnant from their early days. Their domain admins had the ability to recover passwords and for this to work, needed to see them in plain text.

Although company culture can be slow to change, many companies are undertaking the task of bringing their cybersecurity practices into the 21st century.

Logging Sensitive Data

Some companies have found themselves guilty of storing plain text passwords by accident. A well-known social media platform hit this problem when it admitted it had been storing plain text passwords. The platform’s investigation concluded:

“…we discovered additional logs of [the platform’s] passwords being stored in a readable format.”

They had inadvertently let their logging system record and store usernames and passwords as users were typing the information. Logs are stored in plain text, and typically accessible to anyone in the development team authorised to access them. Plain text user information in logs invited malicious actors to cause havoc.

On this point, make sure to use a logging system with strong security features. Solutions such as Coralogix are designed to conform to the most up to date security standards, guaranteeing the least risk to your company.

Hashing and Salting Passwords

In daily life we’re warned to take dodgy claims “with a pinch of salt” and told to avoid “making a hash of” something. Passwords on the other hand, need to be taken with more than a pinch of salt and made as much of a hash of as humanly possible.

Salting is the process of adding extra letters and numbers to your password to make it harder to decode. For example, imagine you have the password “Password”. You might add salt to this password to make it “Password123” (these are both terrible passwords by the way!)

Once your password has been salted, it then needs to be hashed. Hashing transforms your password to gibberish. A company can check the correctness of a submitted password by salting the password guess, hashing it, and checking the result against the stored hash. However, cybercriminals accessing a hashed password cannot recover the original password from the hash.

4. Don’t Expose Your Elasticsearch Database to the Internet

Bob Diachenko has made it his mission to find unsecured Elasticsearch databases, hopefully before hackers do!  He uses specialised search engines to look for the IP addresses of exposed databases. Once found, these databases can be easily accessed through a common browser.

Diachenko has used this method to uncover several high profile databases containing everything from financial information to tech support logs. In many instances, this data wasn’t password protected, allowing Diachenko to easily read any data contained within. Diachenko’s success dramatically illustrates the dangers of exposing unsecured databases to the internet.

Because once data is on the web, anyone in the world can read it. Cybersecurity researchers like Bob Diachenko and Sebastien Kaul are the good guys. But the same tools used by white-hat researchers can just as easily be used by black-hat hackers.

If the bad guys find an exposed database before the good guys do, a security vulnerability becomes a security disaster. This is starkly illustrated by the shocking recent tale of a hacker who wiped and defaced over 15000 Elasticsearch servers, blaming a legit cybersecurity firm in the process. 

The Elasticsearch documentation specifically warns users not to expose databases directly to the internet. So why would anyone be stupid enough to leave a trove of unsecured data open to the internet?

In the past, Elasticsearch’s tiering system has given programmers the perverse incentive to bake security into their database as late as possible in the development process. With Elastic Stack 6.8 and 7.1, Elasticsearch have included security features in the free tier. Now developers can’t use the price tag as an excuse for not implementing security before publishing, because there isn’t one.

5. Stop Scripting Shenanigans

On April 3 2020, ZDNet reported that an unknown hacker had been attempting to wipe and deface over 15,000 Elasticsearch servers. They did this using an automated script.

Elasticsearch’s official scripting security guide explains that all scripts are allowed to run by default. If a developer left this configuration setting unchanged when pushing a database to the internet, they would be inviting disaster.

Two configuration options control script execution, script types and script contexts. You can prevent unwanted script types from executing with the command script.allowed_types: inline. 

To prevent risky plugin scripts from running, Elasticsearch recommends modifying the script contexts option using script.allowed_contexts: search, update.  If this isn’t enough you can prevent any scripts from running you can set script.allowed_contexts to “none”.

Elasticsearch takes scripting security issues seriously and they have recently taken their own steps to mitigate the problem by introducing their own scripting language, Painless. 

Previously, Elasticsearch scripts would be written in a language such as JavaScript. This made it easy for a hacker to insert malicious scripts into a database.  Painless brings an end to those sorts of shenanigans, making it much harder to bring down a cluster.

Summary

Elasticsearch is one of the most popular and scalable database solutions on the market. However, it’s notorious for its role in data breaches. Many of these breaches were easily preventable and this article has looked at a few of the most common security lapses that lead to such breaches.

We’ve seen that many cases of unsecured databases result from developers forgetting to change Elasticsearch’s default configuration before making the database live. We also looked at the tandem issue of unsecured databases being live on the web, where anyone with the appropriate tools could find them.  

Recently, Elasticsearch have taken steps to reduce this by including security features in their free tier so programmers are encouraged to consider security early. Hopefully this alone provides developers a powerful incentive to address the above two issues.

Other issues we looked at were the worryingly common habit of storing passwords as plain text instead of salting and hashing them and the risks of not having a secure execution policy for scripts. These two problems aren’t Elasticsearch specific and are solved by common sense and cybersecurity best practice.

In conclusion, while Elasticsearch has taken plenty of recent steps to address security, it’s your responsibility as a developer to maintain database security.

PCI Logging Rules Your Organization NEEDS to Know

Posted on by eugene evdokimov

For an organization to be compliant with PCI logging requirements, it must follow PCI Requirement 10 of the Payment Card Industry Data Security Standards (PCI DSS). Below, we’ve listed the highlights of this section and the important details that you need to know.

Track and monitor all access (Section 10)

For PCI log monitoring compliance, a critical aspect of data protection is logging and tracking. Implementing logging mechanisms at a company provides the ability to track user activities, which is crucial in preventing, detecting, and minimizing the consequences of a data breach.

Audit trails for user access (Section 10.1.)

To comply with this requirement, organizations need to keep track of user access to all system components. Every user, particularly the administrators, should be monitored over the network and their activities should be checked. This allows organizations to track suspicious activity back to a specific user or administrator. 

Automated audit trails for PCI logging (Section 10.2.)

It isn’t easy to keep track of all systems component access. Requirement 10.2 recommends organizations implement automated audit trails for system components for the following events:

  • All individual user accesses to cardholder data
  • All actions taken by any individual with root or administrative privileges
  • Access to all audit trails
  • Invalid logical access attempts
  • Use of, and changes to, identification and authentication mechanisms and all changes, additions, or deletions to accounts with root or administrative privileges 
  • Initialization, stopping, or pausing of the audit logs
  • The creation and deletion of system-level objects

Log all accesses to cardholder data (Section 10.2.1.)

This requirement states that audit trails log all individual user accesses to cardholder data – pretty straightforward, right? PCI DSS guidance explains that malicious individuals could obtain knowledge of a user account with access to systems in the Cardholder Data Environment, or they could create a new, unauthorized account to access cardholder data. 

A record of all individual accesses to cardholder data can identify which accounts may have been compromised or misused. Whenever someone accesses cardholder data, a log should be generated.

Log all root/admin user actions (Section 10.2.2.)

Accounts that have root or administrative privileges have a greater chance of impacting the security and functionality of a system, as these accounts have full control over a network and they can easily access all sensitive information related to cardholder data.

Requirement 10.2.2 mandates organizations to implement automated audit trails, to log all actions taken by an individual with root or administrative privileges. Logging should record the administrator user name, the areas accessed, the changes made and the time spent.

Log access to audit trails (Section 10.2.3.)

Malicious users often attempt to alter audit logs to hide their actions, and a record of access allows an organization to trace any inconsistencies or potential tampering of the logs to an individual account. Having access to logs identifying changes, additions, and deletions can help retrace actions made by unauthorized users.

Log invalid logical access attempts (Section 10.2.4.)

Invalid logical access attempts are often an indication of a malicious user attempting to gain unauthorized access. This PCI logging requirement requires that organizations implement automated audit trails to log invalid logical access attempts. You should log all of these events:

  • Incorrect password attempts
  • Attempts to view files without adequate permissions
  • Attempts to execute actions without adequate permissions
  • Any failed access attempts

Log all root/admin account usage (Section 10.2.5.)

Similarly to 10.2.2., organizations should implement automated audit trails to log the use of, and changes to, identification and authentication mechanisms, such as the creation of new accounts and elevation of privileges and all changes, additions, or deletions to accounts with root or administrative privileges.

You need to know who logged on and when. When there is a breach, visibility of the active accounts gives you a place to begin investigating.

Log the initialization, stopping, or pausing of the audit logs (Section 10.2.6.)

Stopping or pausing audit logs before performing malicious activities is common practice for users hoping to avoid detection. The initialization of audit logs or clearing of log data could indicate that the log function was disabled by a user. To comply with this requirement, audit trails should log the initialization, stopping, or pausing of audit logs.

PCI logging of the creation/deletion of system-level objects (Section 10.2.7.)

Requirement 10.2.7 requires audit trails to log the creation and deletion of system-level objects.

The PCI DSS defines a system-level object as anything on a system component that is required for its operation, including but not limited to database tables, stored procedures, application executables and configuration files, system configuration files, static and shared libraries and DLLs, system executables, device drivers and device configuration files, and third-party components. Malware often creates or replaces system-level objects on the target system to control a specific function. The purpose of this requirement is to make it easier to determine whether those modifications have been made to any system-level objects.

What should PCI logs contain? (Section 10.3.)

Requirement 10.3 states organizations should record the following audit trail entries for all system components for each event: 

  • User identification 
  • Type of event 
  • Date and time 
  • Success or failure indication 
  • Origination of event
  • Identity or name of affected data, system component, or resource

These components will help quickly identify and provide details related to who, what, when, where, and how compromises occurred.

Time-synchronization technology (Section 10.4.)

Time-synchronization technology helps to synchronize clocks on multiple critical systems. If you do not synchronize these clocks correctly, comparing different log files in different systems to build a proper sequence of events and activity timings becomes very difficult. 

Using Time-synchronization technology, such as Network Time Protocol (NTP) is recommended. 

Immutable audit trails (Section 10.5.)

Audit trails contain all the correct information about events and incidents, so malicious individuals will often seek to alter log files to hide their actions.

To comply with 10.5., organizations must limit access to audit trails to personnel with business-related needs. They must also protect audit trails from unauthorized modifications, back up audit trail files on a centralized server, and write logs for external-facing technologies onto a centralized, internal log server.

The principle of least privilege (Section 10.5.1.)

Audit trails contain sensitive information that only some members of an organization should have access to. If a user does not have a business need to view log files, then don’t grant them access. 

Protect PCI logging outputs (Section 10.5.2.)

Audit trails contain all the correct information about events and incidents in critical systems, so malicious individuals will often seek to modify log files to hide their actions. If an approved individual in an organization finds unencrypted cardholder data or sensitive data in a log, they may want to modify the log file to encrypt this data.

Back up the audit trail files to a centralized log server (Section 10.5.3.)

The purpose of this requirement is to prevent unauthorized modifications to audit trail files. Promptly backing up log files to a centralized log server or media that is difficult to alter keeps the logs protected even if the system generating log files becomes compromised.

Logs for external-facing technologies (Section 10.5.4.)

Organizations should write logs from external-facing technologies such as wireless, firewalls, DNS, and mail servers onto a secure device. This minimizes the risk of those log files being lost or compromised as they are more secure within the internal network.

Use file-integrity monitoring or change-detection software (Section 10.5.5.)

Organizations should use file-integrity monitoring or change-detection software on log files to ensure that existing log data cannot be changed without generating alerts (new data being added should not trigger an alert). Check for changes to critical files and provide notification when such changes are noted. 

Centralize and review security events and logs (Section 10.6.)

Many security breaches occur over a period of time before being detected. How can anomalies or suspicious activity be identified if the logs are not reviewed?

Organizations could meet this requirement through manual reviews by training employees to review log data and identify suspicious activity. Other options are automated methods such as log harvesting, parsing, and alerting tools.

Daily review of all security events and critical system logs (Section 10.6.1.)

Organizations should review the following logs at least daily: 

  • Security events
  • System component that store, process, or transmit cardholder data
  • Critical system components 
  • Servers and system components that perform security functions

Review logs of all other system components periodically (Section 10.6.2.)

Based on the organization’s annual policies and risk management strategy, you should determine which system components should or should not be prioritized for log review.

Simply put, logs not covered in Requirement 10.6.1. should be reviewed periodically.

Act upon exceptions and anomalies (Section 10.6.3.)

Following a log review, an organization must follow up on any and all exceptions and anomalies identified. You must take appropriate actions to any incidents that might be impacting the cardholder data environment.

Keep audit trails for at least one year (Section 10.7.)

This PCI logging requirement expects organizations to retain audit trail history for at least one year, with a minimum of three months immediately available for analysis. The reasoning behind the recommended length of time is because it may take months to notice a security compromise. However, storing logs in off-line locations could prevent them from being readily available, resulting in longer time frames to restore log data, perform analysis, and identify impacted systems or data.

How do you detect failures of critical control systems? (Section 10.8.)

This is an additional requirement for service providers only.

Without formal processes in place to monitor when critical security controls have failed, failures could go undetected for long periods. This provides malicious individuals with opportunities to compromise your systems and obtain sensitive cardholder data.

Service providers must implement a process for the timely detection and reporting of failures of critical security control systems. This could be the failure of things like firewalls, anti-virus, physical access controls, logical access controls, or audit logging mechanisms.

Prompt response to the failure of critical systems (Section 10.8.1.)

This is an additional requirement for service providers only.

Service providers should respond to any failures of any critical security controls promptly.

The organization’s policies and procedures should outline the expected response to failures, which includes how to:

  • Restore security functions
  • Identify and document the duration of the security failure
  • Document cause(s) of failure including root cause, document remediation required to address the root cause
  • Identify and address any security issues that arose during the failure
  • Perform a risk assessment to determine whether further actions are required as a result of the security failure
  • Implement controls to prevent the cause of failure from reoccurring
  • Resume the monitoring of security controls

Are security policies documented, known, and in use? (Section 10.9.)

To comply with this final PCI logging requirement, organizations should ensure that all security policies and operational procedures, monitoring all access to the network resources and cardholder data, are documented, in use, and known by all affected parties.

To summarise

Requirement 10 of the PCI Data Security Standard is directly concerned with network access and security, making it one of the most important requirements in the PCI DSS guidance. 

Therefore, in order for an organization to comply, all the PCI logging policies, procedures, and standards described above must be implemented.

Does Complexity Equal Security?

Posted on by eugene evdokimov

“Teacher somewhere in India: The world you see is supported by a giant turtle.

Student: And what holds this giant turtle down?

Teacher: Another giant turtle, of course.

Student: And what is it that holds this one?

Teacher: Don’t worry – there are turtles all the way down!”

Throughout my years of experience, I frequently encountered solutions (or at least attempts to find a solution) for security issues that were rather complicated and cumbersome, that has led me to wonder if those who came up with them sincerely believe that their complexity and subtlety could improve the safety level in their organizations.

In this article, I will attempt to support the claim that states that ‘very often the opposite is correct’, while towards the end I will present two examples of situations where this rule is intentionally bent in order to improve the security of critical assets.

 

The Scenario

Suppose you have been entitled to protect the building you live in, how would you start the planning process for it? Evidently, you would try to analyze and point out the most critical assets for the enterprise like tenants, letters in the mailboxes, and the bicycles locked down in the lobby. You would attempt to predict the possible threats to these assets and their likelihood. Subsequently, you could effectively reduce the likelihood to an occurrence of one of these threats or minimize its expected risks through a variety of methods. The most common aspect between these methods is that the way in which each method will reduce risk or the chance of realizing one or the other threats, is known to the user.

Often times, in the world of data security or cyber, those in charge of protecting systems do not necessarily understand the thinking process in a potential attackers’ mind deeply enough. Frequently, the result is a network, that paradoxically, is built for managing and maintenance but is easy to break into. 

 

A few examples of weak security:

DMZ – according to its’ common definition, is a network located between the public network (usually the Internet) and the corporate network. While controlled access to servers located in it through the internet and the corporate network will be enabled, access to the internet or corporate network from it will not be enabled.

However, in various organizations, there exist a number of DMZ networks and at times several corporate networks. However, as aptly put by Bruce Shneier in his excellent article ‘The feeling and reality of security’ we, as human beings often respond to a perception of security rather than to security itself. The result of such a reality could be a sharp increase in network complexity and thus also the complexity of its treatment and maintenance. In many ways, such an approach requires more attention to small details on the part of network administrators – and in the case of multiple network administrators, special attention to the coordination between them.

If we were to ask ourselves questions about the vulnerabilities and weaknesses of human beings – at the top of the list we would find the weakness of human beings of paying attention to a large quantity of details over time, maintaining concentration over time, and following complex processes…you can already see where this is going…

Another example: A technique that is frequently recommended for network administrators is to place two firewalls in the organization – both being produced by two different manufacturers in back-to-back configuration. This is done so that if any weakness is revealed in one manufacturer, the chances that the same weakness will occur in the other is rather low.

However, the maintenance of these firewalls would require a large amount of resources, and in addition, the same policy would need to be applied to both firewalls in order to take full advantage of them. As the equipment were produced by two different manufacturers, the updates of the equipment changes and becomes more complex over time.

Once again – if we ask ourselves for another commonly exploited weakness, one of the most prominent on the list would be – lack of consistency.

Parents of several children will notice that all principles of their education that they had acquired from childhood is implemented to near perfection with the first child. Suddenly, with the addition of a second child, that disciplined approach may loosen and by the third child, much more has given way – leaving the elder child amazed at how things have changed.

In our case, when we inquire about the network administrator, he explains that he mainly works in back-to-back configuration, but through a deeper examination, we may discover that he was using two different firewalls made by different manufacturers – each one being intended for a different task. For example, one may be responsible for the treatment of IPSEC VPN and services available online, while another for separating the network from several DMZ servers. In this way, filtering takes place by the first or the second firewall, but rarely by both.

Another great example, but with different content:

Many programmers prefer to develop components on their own rather than using open source components. In their opinion, we can never know if someone changed the code on the cloud to a malicious one. When we have control over our own code, it will naturally be perceived with less danger in comparison to code controlled by people whom we do not personally know. Although, as a matter of fact, a code present on the internet is more likely to be secure and organized, since it is open to the public and therefore has more chances of someone detecting flaws in it and offering corrections.

In continuation to the security risks mentioned above, proprietary code may also lead to the likelihood that it contains bugs – this is due to the fact that such a development also requires continuous maintenance, fixing, and a combination with existing components in the organization, especially when it comes to infrastructure development (queue jobs or pipeline components, for example). The “solutions” to such issues typically lead to cumbersome codes that are difficult to maintain and are full of bugs. In addition, in many cases, the programmer who wrote the code leaves the org or changes roles – leaving the organization with code written by an unknown source…which is exactly the point of proprietary code in the first place.

In many organizations, redundant communication equipment as well as parallel communication pathways are stationed in such a way as to reduce the risk for communication failure as a result of the downfall of a Backbone Switch for example.

It is worth noting that while this type of architecture will significantly minimize the risk for communication loss due to a downfall of communication equipment, and if it is set to an active configuration, will also likely reduce the risk of a downfall due to DoS attacks, it also simultaneously creates new risks: risks of attack or malfunction in looping mechanisms (Spanning Tree being one example).

This results in a number of channels that now need to be secured in order to prevent eavesdropping, and a higher chance that equipment failures will go undetected. Meanwhile packet-based monitoring equipment will be unable to collect the needed information easily and effectively.

It is important to understand – I am not stating that the use of communication equipment in order to reduce the risk of communications downfall or size-based attacks is a bad idea. On the contrary, I am only trying to take everything into consideration whilst making such decisions. I most definitely believe that today, communication equipment are rather reliable, therefore organizations need to understand that redundant communication equipment isn’t a magic solution without downside, and that it needs to be tested against the challenges and difficulties that it poses.

I had promised that at the end of this post, I would present an example that in fact demonstrates a situation where complexity is deliberately used in order to create a higher level of security. One example of such a situation, in my opinion, is obfuscation. It is important to keep in mind that compiling source codes into real machine language such as C or C ++ or GO languages, becomes something that is very difficult to reverse back into readable text, and in large projects it becomes nearly impossible. Therefore, many closed source software programs are written in these languages in order to make it difficult for potential thieves to obtain the source code. However, in many cases, due to a variety of technological reasons, many closed source software also need to contain some parts in non – compiled languages or partially compiled ones (such as #C and JAVA), therefore some source code may need to be protected even when compilation is not a possibility. The solution that was discovered was the obfuscation process which converts the code into hard-to-read code by, inter alia:

  • Transferring the whole code into one single row containing all different classes and methods.
  • Switching variable names, classes and functions of random texts.
  • Add demo code that does nothing
  • Dismantling functions into sub-functions

In conclusion, this post demonstrated how the fact that people are managing data security in organizations is what creates complexity often due to the biases inherent in the human brain. This complexity may contribute to the data security of the organization, but it also aggravates it at times. Nevertheless, I have also shown one example where in certain cases complexity itself is being used in order to improve data security.

The who, the what, the where & when, the why & some AI

Posted on by eugene evdokimov

When you hear the word “permission” what’s the first thing that comes to mind?

For me, it’s the picture in which I’m telling my kids not to do some mischief. It seemes so obvious that permissions in the computer world would be the same: “A user is or is not allowed to do something”, right?

We have all seen this before: User XYZ is (or is not) allowed to read from this file. In other words – it answers the question who is allowed to do what. But is that really all there is to it?

At first glance this does seem to cover everything but sometimes, more often than not, in order for the system to tell whether or not you’re allowed to access a file or a system and maintain a sufficient security in the system, the system also needs to know where from and when are you trying to access the system. For example: if this system is not required to be accessed from certain locations, like a government related website, it would be true to say that regardless of who you are – this type of access should be blocked. Another example would be a secretary that is trying to login to her/his account at let’s say – 02:30AM, it would be considered so abnormal that the identity of the user isn’t that important anymore and this type of access should also be blocked.

Today, most of the systems are already protected by rules that govern what a user (who) can do. Many other systems are also protected by rules that are based on the location – i.e. the where (yes, I am aware of the problematic nature of the accurate detection of the user’s location because of proxies and VPNs but at least these systems do the best they can to detect it correctly). Even fewer systems are using SIEM systems (or others that have similar capabilities) to issue an alert when users are connecting to the system in unusual hours (when) or from unusual locations (where).

In this post I would like to argue that there’s another factor that should be considered: the why. When you come to think about it, it is probably the most important factor. For example, we are not allowed to kill people obviously, according to the law but, there are exceptions to that rule and they are all based on that factor, the purpose. In most countries you are permitted to kill someone who is trying to kill you (and to be honest I don’t know countries that are different in that respect) and of course there are many good examples for that rule.

However, still, in the computing world, we still don’t use this important factor at all. When you install a new app on your phone, you give it permissions, to use the camera (for Instagram for example), to use the microphone (for Waze for example) but we never even think of what do these apps need it for. You give camera permission to Instagram to be able to take and upload your great photos, but in fact it now has the permission to use the camera ALL THE TIME. Even when you are asleep or busy doing other things or using other apps. You give Waze the permission to use the microphone to be able to tell it where you want to go, but now it has the access to use it ALL THE TIME…

So why don’t the companies that dominate this area of technology add this? Well, because it’s hard – very hard. How can you be sure that an app uses the specific resources ONLY for the purpose you allowed?

In this post I would like to challenge everyone who reads it to to harness the power of AI to this field. It is possible to create metrics that will indicate the usage of the feature or resource and then to use that to determine whether or not this app is ALLOWED to use that feature or resource for that specific purpose. At least some of the metrics that should be measured in order to achieve this ambitious goal are already available. If the phone is not in someone’s hand (i.e it’s not moving at all) and it’s not normally used by other apps at this time of day, and it’s in horizontal state and is connected to a charger what are the chances that the user is in-fact asleep and the apps that have permission to use the camera to upload images to the web should not have access to the camera now?

Furthermore, sensors that measure for example the warmth of the hand holding the phone, as well as other sensors, together with some basic ground rules, can help the system predict which access will be needed and deny access automatically when the requested access appears to be abnormal.

Personally, I think that the best AI for such a case would be the NuPic by Numenta because since it is a biologically constrained machine learning, it would be easier for the user to understand why a certain access was blocked but more on that on another post…

Does Open Source Equal Free?

Posted on by eugene evdokimov

Open source tools have been gaining momentum in recent years, largely due to the contribution of several factors, including improved user interfaces, the inability of commercial companies to compete on development quality, the level of support received in open source forums, support for multi-platform open source projects, and the development of small modular interfaces that are interoperable and not interdependent.

But what is open source code? Is it the same as free software? What might be the motivation of an organization that implements such tools? What are one’s motivations in developing in this open source manner? Most importantly – is it profitable?

Let’s imagine for a moment that I’m a pastry chef who managed to bake a cake that nobody’s ever succeeded in baking. I created a cake recipe that explains exactly how to bake it. Without the recipe, there is no cake. In this case, the most important business step should be to keep the recipe totally confidential.

In the world of software, we have a similar situation – the software you run or the page you are currently browsing contains millions of computerized instructions that make the computer do what it does. These instructions are written in a language that computers will understand precisely: machine language.

The problem is that the language of computers is a world apart from how humans communicate – rendering both incapable of understanding each other.

This situation has two solutions: simultaneous translation and pre-translation. This situation, it seems, resembles my home; When I ask my youngest daughter to tidy up her room, she doesn’t always seem to understand the words I am saying, but when I ask my older son to ask her the same question, she tidies up her room very quickly and suddenly I am able to see the rug in the room again…

The assumption is that humans understand English quite well and that software can converts instructions that were initially written in English (more or less) into instructions within a language that the computer can understand. Therefore, there are two options: writing in English and running a program that will know how to translate the English instruction file into a new file written in computer language, or writing in English and running a software that will read English instructions, translate them, and letting that run on the computer until the file is completed.

The essential difference between the two methods is that in the first, at the end of the process you will receive a rather non – understandable file by humans but excellently understandable and taken out by computers, whilst in the second method, the only file produced will be an English instruction file that one can read and change at any moment.

The most obvious advantage of the first method, from a business point of view, is that if I were to write the instructions in English and translated them into computer language, and subsequently gave the result file to someone, it would be very difficult and almost impossible for them to understand my intentions in the computer instructions, that were to make the computer act in the way it was acting. In other words, everyone who were to receive this file would be able to enjoy it as if it were a delicious cake but wouldn’t be able to bake it themselves.

In all fairness, it is also necessary to note that the first method has another advantage in the performance field, as once the English instruction file is translated into computer language, there is no need to re-run the translation job – resulting in a quicker process. However, with the presence of today’s fast processors, in many cases, it is difficult to notice the difference in speed.

Today, in many cases, most software companies still sell software products built with the first method mentioned above, and we are in fact receiving computer file instructions without the ability to fully understanding the way they operate, without knowing how to improve them or/and effectively connect them to other products used. Most software products we use daily are in fact these “cakes” that we are talking about.

In the real world, we are used to a similar concept – many of us purchase vehicles from a certain manufacturer, but not many of us maintain or fix them at the same manufacturer. What prevents a customer who bought a vehicle from one manufacturer from assembling components that are not from the same manufacturer? At the end of the day, nothing. It certainly violates the terms of warranty as no manufacturer support can be expected after changing the components of the vehicle, but technically, this customer isn’t blocked by any limitation. If he were to sell his car in the future, with or without the extras, or decide to dismantle the vehicle due to an interest in its’ mechanics, that would be perfectly legitimate.

The software field is the only field where customers are still limited by these aspects. For example, when a customer buys  software, he agrees to its license not to sell the software or make any changes in its operation. In most cases, even if the customer desires to make changes in the way the product functions or to learn something new about how it functions, this isn’t possible due to the usage agreement or due to the fact that the customer does not own a human-readable instructions file to work with. Due to this inability to read or correct the instructions when necessary, such products (which we receive as computer instruction files) often present difficulties in 3 areas:

  1. Bugs/Security weaknesses: If I were to receive a file containing instructions that could only be read by a computer, how would I be able to tell whether these instructions are matching to what I had initially intended them to do? Perhaps while my word processor prints a file, it also transfers money in parallel from my account to an anonymous attacker, or records my password while passing them to a foreign entity?
  2. Interface components and other software: If the file received is written in a language that only a computer is capable of understanding, it is impossible for software to communicate with other systems and components. Evidently, some software already carries this ability, but connecting the software to a brand-new set of unfamiliar components isn’t a possibility because the file received is unchangeable.
  3. Lack of necessary features: In fact, this disadvantage is an extension of the previous one. When in need of a certain feature, for example language support in a word processor, this is a desired feature that would be impossible to add to a computer language file.

If one is not a particularly talented programmer, it is true that an English instruction file will not be of great use either. However, if the file delivered contains English instructions and is read and operated by millions of online users every day, it is likely that someone has read it – in the case of finding malicious code, he would report that or at least alert other users about its presence. In addition, in the case of a missing desirable feature, it is likely that someone somewhere on the network would have needed to use it in the past and found a programmer that could integrate it into their product.

One of my wife’s friends once stated that any recipe that contains more than three ingredients or an ingredient requiring at least a day of preparation, is automatically deleted from her list of favorite recipes. I believe this is because she was worried that if the recipe would be too complex, she would be prone to making more errors in its’ preparation.

In the world of software too, it is important to emphasize that such instruction files may contain thousands of instructions which would cause the software to function incorrectly (causing the word processor to sometimes replace the default printer, for example) and once again, if written in English (or is accompanied by the original English instruction file), there is a likelihood that many users will have read it and found errors. Therefore there is a high chance that someone has already corrected or reported them.

If there are so many positive aspects to this, why do I still need to pay for software? In other words, if this is such a successful method, how is it that it is not considered as the main approach today? As expected, the answer is…money. A lot of money.

Numerous software houses, throughout history, have almost entirely been basing their business model on one-off development projects (apart from improvements and changes made) and have collected payments from customers. The advantages of such a model for the software house are clear – the development, which is the most expensive part of the process, is established in a fixed period of time, and the implementation of the software for the customer is performed in a very systematic way.

Nevertheless, is this considered the only model for the development of a quality software? The alternative is the open source model. This model is seemingly simple: The developer creates the software and publishes the original software file and instructions for download – enabling users interested in copying, distributing, modifying, learning, 0r using it for free.

This sounds rather impressive, and mostly utopian, but is it truly possible to expect developers to provide such a service without demanding any wages for it? What exactly would be the developer’s motivation to do this job? What extra value would such software products bring?

The motivations for open source development are varied. Some developers decide to develop open source for altruistic or ideological reasons based on collective contributions, and others for anarchist reasons aiming to distance themselves from big software companies.

However, there exists another motivation; there are companies that decide to release their product through the open source approach precisely because their aim is not to sell it. For example, if a large insurance company decides that instead of purchasing human resource management software or document archiving software, it will internally develop it itself in an open source manner which will cause cooperation with numerous other internal programmers, resulting in the rise of the quality of the product and the accumulation of new features, without necessitating a particular development program for the company’s programmers.

In this way, the company, that did not intend to sell the software product in the first place, would not need to invest large sums in their purchase but would invest small amounts on setting up the initial project and its development, whilst the rest would be done by external programmers (private or by other companies) where the ability to use the finalized product constitutes a form of compensation for their efforts in developing the product.

It is important to emphasize that such projects do not necessarily need to be written from scratch – today, open source libraries are rich in components that can easily be combined with one another in order to create a stable infrastructure and only develop the few missing components in an open source manner. In this scenario, we should consider that in the past, a company that wanted to purchase software had to choose between two options: either build the software from scratch at extremely high cost or buy software that would only partially fit its needs – both options do not seem to be ideal.

Nowadays, with the help of open source projects, companies as such can benefit from both worlds: use free infrastructure components and use the help of programmers from around the world in order to meet the exact needs of the company and to receive a product that is tailor-made on one hand, but also very low-cost on the other.

However, it is surprising to consider that there are also numerous commercial companies that choose to develop their products (or at least part of their products) through an open source approach precisely with the aim of gaining benefit. Yes…yes…and how do they achieve this? Companies such as Zabbix develop their product as open source, offer the product for free to all who require it, and charge some customers for consulting and support services.

There are also companies such as Elastic, that offer the core product of the system as open source but charge the customer for complementary products that are offered as part of add-on packages as well as support services. Based on the amount of time that these companies have thrived, one could conclude that this open source model strongly supports their survival.

Another note before concluding: Chinese software users also benefit from the existence of open source traffic – the price of Chinese software is decreasing because the customer almost always (increasingly in the last years) has the option to switch to open source products. The software houses must now offer an attractive price, thus in fact, these open source movements are a benefit for those who support their activity, but also to those who do not.

Finally, the open source has far reaching results on our world today. The price of software is declining, more and more companies are developing products that are used in open source frameworks, while commercial companies are constantly offering their products as open source products, for their own benefit as well as our own.

 

 

 

 

Relevant Links

The adoption of open source in the banking sector:

https://bbvaopen4u.com/en/actualidad/banks-starting-embrace-open-source-finance-and-hackathons-innovate

Bruce Shneier’s article on the importance of open source transparency following the Volkswagen case:

https://www.schneier.com/blog/archives/2015/09/volkswagen_and_.html

Part of the book “The Cathedral and the Bazaar” on the differences between open source and traditional source development:

https://www.isoc.org.il/internet-il/articles-and-research/magazine/the-cathedral-and-the-bazaar

The article discusses the security behind open source in comparison to closed source:

https://www.quora.com/Is-open-source-more-secure-than-proprietary-software