By Felipe Ruiz | April 17, 2020
Earlier this month our CTO, Rafael Alvarez, informed us:
"We’ve already finished the synthesis of the GDPR standard in Rules."
What does that mean?
As Danilo Vásquez —Security Analyst at Fluid Attacks— explained to us,
different GDPR requirements, all of which were considered suitable,
became technical requirements for our company.
That is, they were incorporated into Rules.
Let’s clear this up:
Rules was born there in 2009
(inspired by Common Criteria)
from the combination of knowledge and
"experience in the field of computer security
with various international standards related to this topic,"
according to Oscar Prado —Cybersecurity Analyst - Releaser at Fluid Attacks.
Rules can be defined —following Danilo—
as "a compendium of requirements based on the existing security standards."
Not all general security standards have been covered at this time.
Not all of our requirements are linked to
at least one of those standards we have.
But these are things we intend to achieve in the near future.
The technical requirements (we currently have 189 in 20 categories),
apart from those that may be "out-of-scope,"
are linked to what is verifiable through a technical process in a system.
They are those that can be evaluated with DAST, SAST, or SCA,
techniques that we have already mentioned.
The out-of-scope security requirements, which can focus, for example, on security training and documentation, in contrast, can only be verified by audits. And although they are not technical, as Oscar says, "they play a key role in a security test. For example, the lack of training of an employee can allow a phishing attack to take place." Even some of them may later become technical requirements.
The requirements that we have in Rules
have kept a consistent and simple language, easy to understand.
They allow to delimit a pentesting or an ethical hacking process.
The delimitation will depend on what each client wants to test
and on the concepts of risk and vulnerability that he handles.
The requirements that are chosen
determine the stringency and extent of pentesting.
Hackers have in Rules,
as Paula Vélez, Security Architect at Fluid Attacks suggests,
"a performance guide, because if a requirement is not being satisfied,
that means there is a vulnerability to be reported."
Hacking is made easier; time and effort are saved
if the requirements are found in a single set or single source.
Likewise, clients save time thanks to Rules,
as they don’t have to resort to a multiplicity of standards
that fit their security needs.
In Rules, we synthesize, and we handle homogeneity of expression
no matter the diversity of origins of the base standards.
Rules, as a whole, ends up presenting good practices
not only to developers and configurators of products and systems
but also to other members of the organizations
that can influence their security.
The requirements serve as a guide from the beginning or in full flow.
They serve to prevent the manifestation
or recognize the presence of security gaps
—all this independently of the technology that is being used.
So, we know that many of our requirements are already associated with one or more reputable standards. But what are these standards that currently serve us as references? Let’s finish this blog post by mentioning them.
Health Insurance Portability and Accountability Act,
enacted by the United States Congress in 1996.
As we found in a guide,
this legislation was created, among other objectives,
for the modernization of the flow of healthcare information.
Besides, it was for the stipulation of how
the PII (Personally Identifiable Information),
within the healthcare context,
should be protected by industries to avoid theft and fraud.
The HIPAA comprises five essential rules, each with different requirements.
These rules are: 1) HIPAA Privacy Rule, 2) HIPAA Security Rule,
3) Breach Notification Rule, 4) Omnibus Rule, and 5) Enforcement Rule.
The Application Security Verification Standard
is a project from the Open Web Application Security Project (OWASP),
an online community for the production of freely-available material
in the field of web app security.
ASVS, as we can see on its website,
"provides a basis for testing web application technical security controls."
It also provides developers with requirements oriented to secure development,
protecting from vulnerabilities in web apps.
These requirements can also be used by anyone
who wants to build and test secure apps.
Common Weakness Enumeration, as we found on its website,
"is a community-developed list
of common software and hardware security weaknesses."
The CWE list serves as a support, with a common language,
for the identification of vulnerabilities.
Such identification is essential for their subsequent reduction or repair,
and also for prevention.
The CWE has an orientation towards the communities
of development and security professionals.
It seeks to help ensure that weaknesses in software and hardware
are remediated before the delivery of products,
or that they are prevented to avoid putting organizations at risk.
The National Institute of Standards and Technology,
from the United States, has been active for more than a century.
NIST provides different measurements, standards, and technologies
to support a variety of scientifically based,
human-made products and services, regardless of their size and complexity.
Inside NIST is the Information Technology Laboratory (ITL),
and linked to it is the National Vulnerability Database (NVD).
The NVD, created in 2000, "is the U.S. government repository
of standards based vulnerability management data
represented using the Security Content Automation Protocol (SCAP).
This data enables automation of vulnerability management,
security measurement, and compliance.”
At Fluid Attacks, we are mainly interested
in the NIST Special Publication 800-53 (Revision 4).
It is a database associated with security and privacy controls
for federal information systems and organizations.
Building Security In Maturity Model,
as expressed on its website,
"is a study of existing software security initiatives ."
It quantifies the security practices of many organizations
and describes a common ground and variations.
It is a data-driven model resulting from the analysis
of those initiatives or "_application/product security programs"
to face the challenge of securing the software.
BSIMM’s descriptive model has evolved
in line with advances in the field of security.
It has also grown by collecting and analyzing new data
from new companies and those with maturing programs.
At Fluid Attacks, we use its ninth iteration.
General Data Protection Regulation is a set of rules
within the European Union (EU) and the European Economic Area (EEA)
about data protection and privacy.
These rules also address the collection, storage, and transfer of data
from European subjects outside those areas.
The GDPR enables the unification of international regulations
for organizations processing personal data of European citizens.
It also aims to give individuals more control
over their personal information and its treatment.
Companies are required to apply data protection principles
(using those strictly necessary)
in processing activities and business practices from the initial stages.
Do you want more information about it? Contact us!
Start with Fluid Attacks
Contact us
We are a proud corporate member of the OWASP Foundation
Copyright © 2020 Fluid Attacks, We hack your software. All rights reserved.
