Discussion Post - How to Defend an Organization From Itself

How to Defend an Organization From Itself

When systems have restrictions placed on the security lead’s capacity to execute stress tests or penetration tests, it severely impacts the security perimeter. Penetration testing and stress testing are integral parts of securing systems, as it is one of the main tasks of a security lead to find the vulnerabilities in a system and figure out a way to prevent the system from failing due to the now-known threats (Vats et al., 2019). While penetration tests and stress tests aim to help harden the security, in many cases decision-making executives and management with power do not want to run these tests either due to the associated costs or associated risks to the system. Those choices make the systems less safe, as untested systems that are released into the wild are at the mercy of malicious attackers.

In the scenario in which the executive is making decisions that actively hinder the security lead’s capacity to harden the perimeter, it becomes only a matter of time before a breach or vulnerability becomes a vector to an attack that impacts many of the users and customers in a way that irreparably damages an organization’s reputation. While the rationale for preventing the testing may often be that the system isn’t prepared to handle intentional attacks or disruption, the long-term outcomes associated with that approach are most likely going to have negative outcomes directly related to the decision not to stress-test the infrastructure.

The culture in which executives actively prevent the testing of security perimeters acknowledges that the systems are not capable of handling the stresses which the security professionals are warning to test against. Paradoxically, this approach to security presents an unwarranted dismissive attitude towards security testing while at the same time acknowledging the system likely can’t handle the excess stress. When an organization’s culture has come to a point where security is not a primary concern, they become a danger to their clients and employees alike. In this context, the notion of placing limitations on stress testing and penetration testing clearly becomes an existential threat to every organization that limits its security leads. While there is clearly no organization capable of giving a security team an unlimited budget, security teams cannot have their work be limited by philosophical resistance to stress and penetration testing as these approaches are critical for the safety and security of any infrastructure.

In terms of examining built-in security compared to bolt-on security, the different approaches both have benefits and drawbacks that make it necessary to take some of the aspects of both in terms of establishing a hardened perimeter. On the one hand, the built-in security is meant to have a base-level foundation of protection that applies across the entire build, as it is implemented before the project is deployed. While this may come in the form of access control, firewalls, or intrusion detection, built-in security is typically a protocol that is meant to persist in the form in which it is deployed for the duration of the software’s life cycle. On the other hand, the bolt-on security approach is implemented after the software has been deployed, and is an additional layer of some sort that is meant to harden security. This could come in the form of SSL encryption, DDoS protection, or a third-party add-on service of some type.

One term that has been used is a “Secure Development Lifecycle” or SDLC as a way to describe the section of development that is specifically focused on formulating the security protocol (Shunami, 2017). The type of development approach being taken by the team will also influence which approach to security will best serve the users long-term. The SDLC will differ in the context of a waterfall or scrum approach compared to that of a devops approach to building software (Shunami, 2017).

Another influential factor is the cost of implementation at any given point in the Software Development Life Cycle. The closer code gets to deployment, the higher the cost associated with adding certain aspects of the security infrastructure or fixing bug-related vulnerabilities becomes (Shunami, 2017). As well, the costs associated with simultaneously implementing security software and dealing with fixing the fallout associated with a breach or vulnerability are inherently higher than implementing the security measure before launch.

Even though there are many security threats that can be anticipated, the zero-day threats are a vector to which built-in security measures are not well-equipped to handle in general (Shunami, 2017). It is in this gap that the bolt-on security approach becomes more practical as a solution with the understanding that some threats are completely new and could not have had any security in place to prevent the impact (Shunami, 2017). In this context, it is a combination of built-in and bolt-on security that would make the best approach to ensuring the fitness of an organization.

While the process of securing a perimeter and establishing the authentication levels for users can overlap, these two aspects of infrastructure are not the same. It is necessary to articulate them as different in that if a person’s identity becomes compromised, that should not necessarily simultaneously compromise their associated authenticated access. In that same vein, a person who has had their authentication compromised can use identity verification to re-establish their authentication permissions. Having these two systems overlap too much can create a situation where the user has both their biometric data and authentication access compromised, effectively locking them out of the system completely.

When analyzing the concept of whether biometric authentication is truly performing authentication, there are some caveats that must be addressed to determine whether the system is actually authenticating the identity, the biometric, the user, or a combination. In a sense, biometric authentication only cares about the metrics being measured to match them against each other. Authentication can only authenticate what is within its database, thus a system can only authenticate within the limits of its orders. In the case that there is not a match, the authentication process fails, and access is denied.

On the one hand, this would seem to be a fairly secure method of access control, but upon further analysis this quickly proves not to be a great method of either securing a perimeter or authenticating an individual. In an example where the individual’s face is the biometric being used, a photograph or a mask can be used to circumvent some biometric access control mechanisms making it clear that the authentication aspect is not as simple as it may first appear (Datta et al., 2020). While a biometric like an iris scan may be more secure than voiceprint or fingerprint, using these biometrics in tandem make it much closer to an authentication mechanism, however there are still ways in which biometrics can be used to have even higher levels of authentication, while still not being able to achieve true authentication.

Another scenario in which biometrics would be closer to authentication is if the biometric database is being held and confirmed by a government third party. In the case where the biometric data was originally recorded by a third party, authenticating the identity of the individual associated with the biometric becomes possible, but that also creates another security risk in establishing a connection to the third party that is transmitting sensitive data(Datta et al., 2020).

This increased security risk becomes a trade-off for a heightened level of authentication, but in this context it’s not the biometric doing the authentication it’s the third party using the biometric to confirm that the person using the access control obtained the biometric data or is the person that is the originator. As automated systems cannot yet distinguish between a person’s biometric data and a person who successfully fakes the biometric data, the process can only indicate that the biometric data used in the access control is the same biometric data that is in the database.

If a system cannot handle a penetration test, it will surely not be able to handle a malicious attacker. Organizations don’t have to rush to hire a third-party security specialist out the gate and the IT team can secure tools that make it easy to run sophisticated penetration tests on your own system. Since security should be an iterative approach that is never finished, this type of penetration test should happen frequently and unexpectedly to prevent the security from getting lax.

Supervisory Control and Data Acquisition (SCADA) FRAMEWORK

The SCADA framework is particularly useful in different settings because of the focus on access control as well as data gathering, and in that context, it establishes an agile approach to securing different access control points while analyzing the data in the system to better secure it. The increasing complexity of the types of attacks that are happening to organizations necessitates a robust testing ground in which the newest threats and vulnerabilities can be assessed to understand how to harden security against them.

References:

Datta P., Bhardwaj S., Panda S.N., Tanwar S., Badotra S. (2020) Survey of Security and Privacy Issues on Biometric System. In: Gupta B., Perez G., Agrawal D., Gupta D. (eds) Handbook of Computer Networks and Cyber Security. Springer, Cham

Shunami, B. (2017, September 28). Baking Security Into the Development Lifecycle — DZone Security. Retrieved from https://dzone.com/articles/baking-security-into-the-development-lifecycle

Vats, P., Mandot, M., & Gosain, A. (2019). A Comprehensive Literature Review of Penetration Testing & Its Applications. Available at SSRN 3470687.

6 Likes

Recently I’ve been delving into not only blockchain’s security but also cybersecurity in general - currently beginning work on a thesis related to this topic - and so I decided to start from a solid post like this.
In the case that a known vulnerability is intentionally hidden, it becomes essential to provide a safe and controlled testing environment.

According to the very logic of what you wrote, security implementation costs become a function of time; the longer you wait to implement security measures that are or will be needed, the higher the cost. I suppose that you could separate this into several stages, where cost naturally increases with each stage:

  1. Parallel implementation of system with security measures
  2. Implementation of security measures after system implemented but before launch
  3. Implementation of security measures close before launch
  4. Proper security measures taken after controlled, internal breach occurs
  5. Security measures taken after external attack occurs, while effects of breach are being simultaneously managed

With that being said, an interesting question would be to what extent this would apply if the security measure is not guaranteed to be needed, but rather has only a small chance of being needed.

This paragraph nails the conclusion of your entire post well. By the way, would you happen to know how universal the SCADA framework is? Also, to what extent can the security measures you mention be applied to implementation of new blockchain systems?

2 Likes

Thank you for the comments and additions to the thread!

Relative to how ubiquitous SCADA implementation is, it is a fairly common approach in IT across different industries and is one of the standard methods concerning large-scale hardware/software deployments. There are variations, but relative to Distributed Control Systems or the IoT approach, SCADA is going to be one of the most pragmatic ways to deploy a network to ensure that it’s “safe” for the users.

One of the main reasons I wanted to post this particular approach on SCRF is to get more developers in the blockchain space to think about this type of approach. I believe if there is a standard of auditing and threat assessment taking place from a group of third party operators, it will make the entire ecosystem more secure and by proxy make it more likely that a deployment will be safe for the users.

While the crypto space tends to focus on smart contract and code audits, adopting the SCADA approach would expand the scope of vulnerability assessment to a point where it would definitely consume more time and resources, but with the immediate result being deployments that are safer earlier.

3 Likes

It certainly makes sense to adopt a comprehensive approach to ensuring the security and stability of large-scale deployments, such as those used in distributed control systems or the Internet of Things (IoT). The SCADA (Supervisory Control and Data Acquisition) approach, which involves monitoring and controlling industrial processes through remote devices, can be an effective way to manage and protect these systems.

Conducting regular audits and threat assessments by a group of third party operators can help identify potential vulnerabilities and weaknesses in the system, and implementing measures to address these issues can increase the overall security and reliability of the deployment. This type of approach may require more time and resources, but the benefits of a safer and more secure system can be well worth the investment.

It is important to recognize that security is a ongoing process, and regular monitoring and assessment is necessary to ensure that systems are protected against evolving threats. By adopting a comprehensive approach like SCADA, developers in the blockchain space can help create a more secure ecosystem for their users.

1 Like