LevelBlue Completes Acquisition of Cybereason. Learn more

LevelBlue Completes Acquisition of Cybereason. Learn more

Services
Cyber Advisory
Managed Cloud Security
Data Security
Manage Detection & Response
Email Security
Managed Network Infrastructure Security
Exposure Management
Security Operations Platforms
Incident Readiness & Response
SpiderLabs Threat Intelligence
Solutions
BY TOPIC
Offensive Security
Solutions to maximize your security ROI
Operational Technology
End-to-end OT security
Microsoft Security
Unlock the full power of Microsoft Security
Securing the IoT Landscape
Test, monitor and secure network objects
Why LevelBlue
About Us
Awards and Accolades
LevelBlue SpiderLabs
LevelBlue Security Operations Platforms
Security Colony
Partners
Microsoft
Unlock the full power of Microsoft Security
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings

Positive security model in ModSecurity

One of the major improvements in the next release of ModSecurity (v2.0) will be the support for a positive security model. Even now, with its flexible rule language, ModSecurity supports the positive security model. But there are areas that are not covered (e.g. automated policy generation is difficult to achieve) so I have decided to provide a complete solution for this problem.

I have been looking at the possible solutions for a positive security model for some time now. There are three ways to solve the problem:

  1. Strict and comprehensive resource and parameter checking.
  2. Statistics-based anomaly detection (a very interesting paper on this subject).
  3. Anomaly detection based on neural networks.

I have decided to start with the first option, mostly because this approach is easy to understand and allows whitelists to be created and/or updated manually. Furthermore, it may be possible to get the developers to distribute positive security model configuration files with their applications. Automated tools may be used to create these files in the first place. Below is a quick overview of what I have in mind:

  • Access to some areas of a web site need not be controlled (allow all).
  • Access to some areas of a web site must never be allowed (deny all).
  • Web site is a collection of resources (e.g. scripts).
  • Each resource can be used in one or more different ways (resource profiles).
  • Each profile needs to support a different set of parameters. (For example, one set of parameters is used when the resource is invoked with GET, another set of parameters when resource invoked with POST.)
  • Parameters are identified by their name, type (field or file), cardinality, character class (or a fixed range of acceptable values), and length (minimum and maximum).
  • Additional support for parameter arrays (dynamically created paramters) is needed.
  • Support for parameters transported in PATH_INFO is needed.
  • Support for parameters transported in the URI (e.g. URI append) is needed.

A full XML-based configuration file example is available here.

ABOUT LEVELBLUE

LevelBlue is a globally recognized cybersecurity leader that reduces cyber risk and fortifies organizations against disruptive and damaging cyber threats. Our comprehensive offensive and defensive cybersecurity portfolio detects what others cannot, responds with greater speed and effectiveness, optimizes client investment, and improves security resilience. Learn more about us.

Latest Intelligence

Discover how our specialists can tailor a security program to fit the needs of
your organization.

Request a Demo