Among Ukrainian organization, we get the most requests from IT companies, and in this post, I want to talk about some accumulated experience. Quite possibly, it will be useful to other organizations in this business, and maybe organizations from different sectors. So if you know a CIO/CTO from an IT-firm, show them this text. It was written for them.
The IT companies request security services by their initiative in about one of ten cases. In other cases, the reason for such a request is a requirement of the customer or potential customer. Unlike many of my colleagues, I consider this approach to be quite right, practical, and cost-effective. These companies write the code for their clients. This code, in most cases, benefits their customers and makes the lives of many thousands of people more convenient.
Therefore, to require IT companies to take care of security is up to either their customers or their customers’ customers. Some virtual Vlad Styran can be deeply concerned about the sad state of software security, but it would be better if he and his associates founded a local OWASP chapter and made the application security knowledge available in their region. What is exactly what he did.
But, at the same time, the “security” requests from IT companies are a bit chaotic, and here let’s dwell into more detail. I see the cause of it in the dualism of the notion of security in any organization that creates information products or services. On the one hand, there is organizational security: protection of systems, networks, and intellectual property, compliance with local and international regulations, etc. That is, protecting the interests of the business in essence: by not allowing it to go bankrupt and its leaders to end up in jail.
On the other hand, there is security engineering: protection of products and services from abuse by unauthorized persons, protection of users and their data from consequences of such abuse, and protection of the business model from both third parties and authorized users (for instance, software licensing and DRM). That is the protection of the product and its ability to turn into profit.
Needless to say, these two types of security are quite different areas of knowledge. Unfortunately, this fact is unknown to way too many leaders. Sometimes this causes application security to fall into the operations security management’s responsibility, which results in a lot of additional friction in the relationship of IT and business. Much less often, software security management is assigned operational security tasks – that’s when the real drama begins. In a fairy tale with a happy ending, in both cases, all actors eventually reach consensus and distribute duties more or less naturally. Otherwise, it sometimes leads to work conflicts, and then everything depends on the diplomacy and professionalism of its participants.
To make life easier for executives of IT firms and their subordinates, I will formulate a simple algorithm for deciding where particular security responsibilities should be placed in an organization.
1. Find out what you are protecting:
A: the firm, with all its assets, personnel, financial secrets, from cybercriminals and the requirements of laws and industry standards,
or
B: the product/service that the company produces, from cybercriminals and malicious user actions.
A.2. In the first case, trust the security professionals who are engaged in the technical protection of information and organizational security measures. Such specialists normally come from the banking system or IT integrators and distributors. In the past, they usually were the employees of IT operating units: system and network administrators. Sometimes – law enforcement officers.
Keywords: CISSP, CISM, Information Security, Security Administration.
B.2. In the second case, assign the task to the software security professionals. Such specialists are less numerous in the job market and have somewhat different skills. In the past, they were programmers, QA/testers, or started in Application Security. Most likely, they participate in Bug Bounty programs in their free time.
Keywords: OSCP, OSCE, Application Security, Bug Bounty, White-Hat Hackers.
A.3. Methodological recommendations and industry standards (that is, instructions on how to build security when you do not know how to do it) are all over the place. Most likely you will deal with ISO 27001, SOC2, NIST, CIS, or another framework. Take this into account when choosing the management and operational security staff.
B.3. As for software security, there are also recommendations here, but with much fewer standards so far (and in my opinion it’s good). Recommendations can be searched for by the keywords OWASP, SAMM, SDL, NIST. The leaders of the secure development business functions should have not only a general comprehension of these processes but also be able to implement and improve them effectively.
A.4. The involvement of external consultants in the technical and organizational security can take place in many forms, but usually, it is either building something faster than you can do yourself or checking the quality of your security measures. Audit and consulting in this area are quite profitable activities if you understand what I mean. Therefore, you have to be very cautious at all stages of the formulation and implementation of projects, since the scope creeps start at day one, and unaccounted expectations may appear in the final stages.
Keywords: CISA, CISSP, ISO27001LA, ISO27001LI, Penetration Test, Security Audit.
B.4. Involving an external resource in the secure development processes is possible at almost all stages of building the software except for the formulation of the business idea. Design, architecture, planning, implementation, testing, deployment, support, incident response – all these and other phases can be performed in-house or outsourced. But this is a thing: at a particular stage of the project development, the existence of internal application security function will become much more efficient. Independent security testing and ad-hoc consulting services are likely to remain helpful from time to time, but in the process of developing, refining and integrating a product, your software security specialist or even an entire unit will become relevant.
Keywords: OWASP, OSWE, OTG, ASVS, SAMM, Application Security Assessment, Application Penetration Test.
5. The placement of a security unit in the organizational structure is a complex and dramatic theme. Many advocates of “good practices” in security management insist that Chief Information Security Officer (CISO) subordination to the CIO is a bad idea, as this creates a conflict of interest: the IT director pursues the availability and performance of systems and services when the security leader imposes a bunch of restrictions on them. In the case of organizational security, this statement might be appropriate, but when it comes to the subordination of security to the CTO in a product organization, the conflict disappears, because it is the CTO who is interested in the security of developed services and products.
Hopefully, these notes will help you navigate the subject and select the right strategy. Or at least save a bit of time. Take care.