Loading...It makes sense when you think about it: the strength of a chain is defined by the weakest link. And multiple recent reports highlighted the fact that in digital security, the human factor remains the weakest link. No matter how strong a fortress you build, if someone leaves the door open, you’re wasting your time.
What is an acceptable level of security?
As Pentalog’s incoming Chief Security Officer, my objective is not to achieve the highest possible level of safety, but rather the best level that serves the interests of the company and its customers, whose destinies are linked. To achieve this goal, we must armor the ship on both the port and starboard sides.
On the port side, this means understanding the internal operations of Pentalog, working with all teams, all businesses, all countries, to identify a level of safety that is both acceptable and a driver of performance. This means working with our senior leadership so that security becomes everyone’s subject, not just mine. The goal here is not to generate income, but to save money, which is not easy to measure.
It happens that while we can precisely determine the cost of security, it is much harder to measure the benefit. If we do the job well, maybe nothing will happen for a year. But correlation doesn’t imply causation, and just because nothing is happening doesn’t mean the job was well done. Maybe we just got lucky, who knows? We need to start with clear measures of success for internal security.
On the starboard side, we think about what Pentalog offers customers in terms of security. Here we want to focus on two services: SecOps and pentesting. We think of these services as in addition to providing our clients with top-level projects. By enhancing a team member with security skills, we integrate the concept of security directly into the development roadmap.
This is what we call “security-by-design.” When a security engineer works with developers this lets us define a flow where each code release complies with security good practices. Doing so gives us the best chance to ensure that code is checked before being put into production. Once code is online, the focus turns to ensuring that the development logic does not give rise to unexpected behaviors in production. This is the moment to conduct intrusion testing (commonly called pentesting), to assess security under real-world conditions. SecOps and pentests are two sides of the same coin, indivisible and essential to sustainability in production.
Want to learn more? Get to know Logan Fernandez and learn about his approach to digital security by watching this video.
We Think of Penetration-Testing at 4 Levels
- Assessment: In two days, we quickly check that there are no visible vulnerabilities. Let’s compare our application to a house: the evaluation would consist of going around the building to make sure that no windows are open. If a window is open, we stop there and report it immediately.
- Black box: This involves hacking the application by putting yourself in the position of an attacker who does not have any information or connection identifier for the application. This would involve walking around the house to make sure no windows are open. In case of an open window, we will enter the house to see if we can reach other rooms and find any valuable items. When we do, we report it immediately, with recommendations for resolution.
- Gray box: The most common practice is to perform a 2-week audit combining Assessments, Black Box, and Gray Box techniques. Here we put ourselves in the situation of an attacker who has login credentials to the application. That is to say, the attacker would have the keys to the house, obtained either voluntarily (by an employee, the famous “weak link”) or unintentionally (a theft), and would break into the house to steal documents, valuables, perhaps stored in locked rooms, or even a home safe.
- White Box: This consists of sharing the source code of the application with a team different from the one that developed it, to obtain double control of the level of security of the application at the level of the code itself.
Security is Never Just for Technical Teams
The more successful a business becomes, the more it becomes a target. You can think of this unwanted visibility as a side effect of generating income. This makes it essential to be able to identify a level of security that is not only sufficient to comply with applicable regulations (such as GDPR, e-Privacy, PCI-DSS, etc.), but also to ensure business continuity.
This is where security becomes a matter of governance, establishing measurable security objectives and translating them into concrete action plans, which have an impact on all activities. This involves devising a risk management plan and security policies to govern business operations. We rely on governance to integrate security into all projects (think about password management policies, IT charters, access permissions and rights management, etc.).
But the most important thing, after all these steps, is to get back to the weak link: the human. Employees must be trained on a regular basis. Can we imagine a team member leaving the door open by mistake? Of course! Think of all the energy we spend updating operating systems and correcting software bugs. Isn’t it obvious that human beings need the same kind of regular attention?
Our goal must be to raise the general level of maturity in terms of security, well beyond the domain of technical experts, so that it becomes a foundation of success and sustainability for the future of our business and for ourselves.
Want to learn more? Get to know Logan Fernandez and learn about his approach to digital security by watching this video.
