We've Reached a New StandardMore requirements in Rules are firmly supported
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,
GDPR requirements, all of which were considered suitable,
became technical requirements for our company. That is, they were
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
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.
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
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.
Figure 1. Photo by Mathieu Perrier on Unsplash
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
HIPAAcomprises five essential rules, each with different requirements. These rules are: 1)
HIPAAPrivacy Rule, 2)
HIPAASecurity 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
CWElist 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
CWEhas 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.
NISTprovides different measurements, standards, and technologies to support a variety of scientifically based, human-made products and services, regardless of their size and complexity. Inside
NISTis the Information Technology Laboratory (
ITL), and linked to it is the National Vulnerability Database (
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
NISTSpecial 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’sdescriptive 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
GDPRenables 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!