In two posts I published previously, I had already mentioned Open Source
Software
(OSS). In the
first one, I remember quoting Gardner,
referring to the increasing use of OSS by development teams in
charge of building applications. In the second
one, which may serve as an introduction to this
post, I addressed some generalities about OSS, its differentiation
from proprietary software, and some of its benefits as a business
strategy. For this post, we’ve decided to give more room to the security
of OSS and briefly present our experience at Fluid Attacks
.
About two months ago, Nivel4 reported that the source codes of three Mexican banks' mobile applications had been leaked and revealed on the web. Some people on the networks commented that the cause of the leak was a misconfiguration, and the banks immediately reported that there was no impact on the security of the systems and customers' sensitive data. Was it true? I believe that many people were suspicious of such security on the spot. By the way, if there was nothing to lose by showing the code, why did they keep it out of sight? These banks undoubtedly lost users' confidence and reputation among competitors.
The applications of the three banks inadvertently became OSS. We could say that their owners intended to maintain a security image by not making public the code. However, hidden or open, the code’s security will depend on how solid and qualified its elaboration has been. Vulnerabilities or flaws can be found in both open and proprietary software, but as Byfield shared some years ago, "proprietary software vendors are notorious for security by obscurity." They usually erroneously believe that keeping their systems in the dark caves will make them more secure. Therefore, in many cases, they perform a few security assessments and patch vulnerabilities relatively slowly.
One of the most mentioned business benefits of OSS is, contrary to many people’s intuition, security. When we talk about an OSS project widely recognized on the web, we can say that many eyes are scrutinizing it and many hands are testing it regularly. Consequently, the chances of overlooking cybersecurity risks are much lower than when the project is private. A large community with a wide variety of members can detect and fix vulnerabilities in the code much faster than a small group of developers belonging to a single company.
Nevertheless, I should note that many companies keep their code secret,
some of them at the same time pretty well secured, for no other reason
than to preserve as their own the idea that makes them unique against
their competitors. That’s comprehensible. However, some hide only their
"essential" portions of code and expose the rest on the web to benefit
from working in open communities. That’s what, according to
Brikman,
for example, Google does with their "primary differentiator[:] their
search architecture." Meanwhile, many companies that share all the
code to the general public, generating confidence by the security they
provide, can receive income through other
means,
including offering services related
to their OSS. They have their "secret
sauce"
located elsewhere, and here’s where Fluid Attacks
comes in.
Fluid Attacks is safe, out of the cave
Fluid Attacks
was born directly in the free and open-source software,
making use of it and keeping it in that condition.
As Gomez,
co-founder of the company, said,
they started working directly on Linux
and were in charge of networking,
based on OSS,
before becoming a red team
in 2008,
which has not stopped sharing its code.
Code that is not exclusively adhered to a pair of privileged minds
on which it'll always depend to exist and operate.
Whenever someone leaves Fluid Attacks
,
someone else with similar skills and experience will take over
because the raw material
with which we work
will never cease to be shared.
Apart from the collaboration that we can receive from smart people of
our community and not legally
affiliated with our company, almost all Fluid Attacks'
members can and
are encouraged to review the code to propose new ideas for its
optimization (including security). Since Fluid Attacks’s
inception,
we’ve taken advantage of OSS as an organization, and we’ve also
committed ourselves, on a reciprocal basis, to generate our contribution
to the overall cybersecurity community.
Could then someone ask us, aren’t you giving away work that has cost you so much? Aren’t your competitors watching in detail, even copying, what you use to serve your customers? Couldn’t keeping an OSS mean giving away the necessary material to other groups of individuals to establish new companies and more competition for you? And, perhaps more importantly, aren’t you highly vulnerable to malicious hackers' attacks by exposing your code?
In response to these questions, we can say that what we’ve built so far has also been partly thanks to many people worldwide who have maintained the OSS movement. We can also say that we feel comfortable making knowledge public, gaining experience and reducing duplication of effort. Additionally, we rely on our primary differentiator —which is not in the code— to stand out from old and new competitors. As I said, our way of making profits is not focused on offering a code but services from human intelligence using that code. Finally, revealing our code doesn’t make us highly vulnerable to attacks, as long as it has the necessary security controls and its vulnerabilities are reduced to a minimum.
It’s imperative to note that the code we publicly display is not just the same code we use in our clients' security benefits. It’s also the code that serves to carry out our systems' and products' security analyses on an ongoing basis (Continuous Hacking). We’re not giving the community a batch of mediocre and half-baked lines of code. The material we develop and fervently update at an accelerated pace is our analysts' material day by day. At the same time, it’s the stuff that can be used reliably by anyone in any corner of the planet to detect vulnerabilities in IT systems.
At Fluid Attacks
, we understand that having a hidden code is not
necessarily keeping it safe. We comprehend that security depends on the
code’s strength and quality, which preferably should be reviewed by many
people and continuously. So, we don’t hide the code. There’s no mystery
behind what it can do. What we keep hidden and safe is our company’s and
clients' sensitive data, using complex encryption processes, for
example. That’s what we help many companies to achieve (discovering
vulnerabilities and promoting better development practices) and what we
give to you as a recommendation here.
Inside or outside the cave, your security will depend on your armor, weapons and skills. We can help you, and the community can help you improve your security. Leave the cave voluntarily (do not wait to be taken out like the banks). It’ll reflect confidence, strength and transparency to your followers, clients or stakeholders. Later, you’ll even be able to generate, facilitate contributions to the community. Just contact us!
P.S. Take a look at our code here!
Share
Recommended blog posts
You might be interested in the following related posts.