General – CreationsAustin

MS CRS: Information Systems Security Engineering

Review CISA List of Tools and Services

I looked for Cybersecurity tools that would be most useful and approachable to a small/mid-sized company, specifically regarding protection of the internal network, intellectual property, workflows, etc. Areas to keep in mind include technical requirements, coding skill levels, surface area monitoring, information sharing, and initiation costs. Examples used in this document were from the CISA list Cybersecurity Best Practices Services.

Some of the areas of importance to a small business include:

Is it a service or a tool?
Surface area monitoring including passwords
Scan for weaknesses regularly
Does it require coding required or not (and what languages it is compatible with)
Updated information sharing
Latest vulnerability tables; how many and which ones
Knowledge Bases, Help files, Initiation videos, etc.

Services

There are many services out there that enable a company to outsource its security. This paper discusses tools and removing services from review.

Tools

There appeared to be three main categories of tools:

Code as Security (within a development pipeline),
Customizable suites that require coding literacy, and
Customizable Identity and Access Management (IAM) tools, that require a high level of technical literacy but do not require full coding literacy (at least at start).

Code as Security

The first category, Code as Security, are the tools that require coding skill, knowledge, and understanding. This subset of tools help within the development pipeline, but are not coverage for the business as a whole. For example, tools like Google OSS-Fuzz are useful to a company that has a development team, perhaps sells SaaS, and coders within the IT or Security team. OSS-Fuzz and similar Security as Code tools would be handy within the development pipeline, but don’t represent a full coverage or protection suite.

Customizable Suite of Security Tools Requiring Coding

The second category, Customizable suites of security tools require development level personnel; the amount of command line and other coding language required is high. Using Gripe as an example: It would require an internal dev team to establish, create the dashboards, and to manage it. This sort of tool requires keeping a portion of developers available for monitoring, updating, and keeping up to date not just on the dashboard and metrics tracking, but to also watch, and maintain the software itself. Many of these tools are available on Github, BitBucket, or other repository systems. Constant review and tracking of source files and updates would be necessary, as well as monitoring different boards for latest risks to track if the chosen tool is keeping up to date. If a company is going to establish a security team for this, they then have to watch the tool development itself – to ensure the tool remains safe, and that use of the tool remains up to date with the source code. Selecting this type of tool likely requires a full time CySec officer and team.

Cloud Protection Suites & Identity Access Management

Cloud Protection suites that include the Identity and Access Management (IAM) tools are our third tool category. These are larger protection suites, often provided by the cloud provider. Microsoft Entra ID (formerly Azure Active Directory), Google Security Command Center and AWS AIM, fall within this category.

These tool sets require a good understanding of technology, but do not require a team of coders and developers to manage them (at least to start). These tools have ability to build the reports and graphics required to convey complex data upstream, and have enough technical power to input work flows, track exposure & surface area, odd behavior analytics, and constant monitoring of the known surface area within that environment.

These larger tool sets, that include Identity Access Management (IAM), are an accessible starting point for many small to mid-sized companies. The dashboards that come with these tools can be used to help identify areas of exposure that may require looking for addons. Each of the above-mentioned toolsets have marketplaces for additional functionality, including third party vendors.

Of the three tool sets mentioned, we will more fully explore Google Security Command Center (SCC), because it has the easiest/simplest point of entry for a small to mid-sized company that may not have developed Access Management or Cybersecurity previously. Discussion of third party compatibility as a deciding factor will not be explored here.

Entra, AWS, and SCC tool sets have similar abilities and set up requirements at the small to intermediate business level. — Entra, AWS, and SCC tools sets have similar abilities and setup requirements.

Google Security Command Center (SCC)

Google Security Command Center is a cloud-based security platform that will monitor the attack surface area, and alert the operator to threats, weakness, incorrect configurations and more. It is set up with the ability to prioritize or “threat level identify” the threats. SCC allows the operator to select and view what the threat is, why it is a threat, and recommended mitigation and/or solutions.

Setup

The Google Security Command Center is the most approachable service of the three mentioned above, and has some of the best introductory materials to facilitate small to medium companies to be able to accomplish that initial lift required to gain that first step into Cybersecurity.

The initial setup of Google Security Command Center requires setting up the Google IAM, from within the Google Cloud Platform -> IAM page.

Setup even for the IAM requires 5 roles within the Google Cloud Platform -> IAM permissions page[i]. The operator setting up the SCC will need to setup and establish the organization, and select the services.

The “Standard” (free) level built in services include Security Health Analytics, which can identify misconfigured virtual machines, containers, networks, storage, and identity and access management policies. For the Standard tier, the level and depth of scanning is at “high level” misconfiguration, and can be increased in coverage with purchase of a higher-level service. For example, If the company requires API keys scanning or rotation or other configuration issues, they would be looking for moving up from the Standard to a Premium tier. Understanding and researching the difference in the different tiers would fall upon the team member(s) setting up the security. However, even starting at the free or “Standard” tier is better and more security than choosing not to do it all.

Initial work starts with the Identity Access Management (IAM), the operator setting up the SCC will have to communicate across multiple teams and stake holders; developing roles, permissions, and standards. This is not unique to the SCC; it would be required of every IAM tool or platform. There are times that cyber security and resiliency has dependencies, where one process cannot be implemented until another is accomplished[ii]. Understanding permissions, roles, groups, and access is a requirement that must be accomplished to achieve any level of cyber security coverage.

Secondary set up would be to define areas of interest. Correctly establishing the services, providers, data bases, and exposure points is necessary for the tool to be able to monitor and report on attack surface areas and traffic flow. Again, this is not a unique cost, but it does represent required resources and should be considered.

Once fully set up, the SCC has the ability to continuously monitor the attack surface area, provide reports, and suggests paths of control, response, and remediation if needed. The initial scan will likely take longer than usual (hours) but after that, Standard plan service runs a scan twice a day.

GC: SCC SWOT — Google Cloud, Security Command Center — SWOT

Some areas of opportunity may also be considered weakness – for example not having a report (weakness), but having third party integrations that build reports (Opportunity), what is the security of that third party and who is responsible (Threat). With that in mind, lets get a litter deeper.

One of the greatest assets to a system such as this, is that as part of a behemoth tech company, these systems of tools have access to some of the largest resources for monitoring, development of tools, remediation of their own defects and the discovery and management of the latest threats. This is an asset for the small to medium companies because there is no way that a single individual or single team, can keep up with the constantly changing threat landscape. Keeping that task on the tool-set, is a huge asset to a small company.

There are challenges, no product is perfect out of the box. Each of the listed tool sets can integrate with many third parties for more targeted coverage and reporting. Google Security Command Center has the Google Cloud Marketplace where there are thousands of compatible add-ons, services and tools. If the operator doesn’t find an exact match, they are likely to find something that comes close. Some of these integrations will take more work if they are native to a different platform, and it should be considered when deciding on a cloud protection system.

Of course there are differences between AWS, Entra, and Google options. A simple example is their firewalls; at the time writing this document, it appears that AWS offers AWS VPN (Site to site, and point to site) where Google offers Cloud VPN (Site to Site). Google’s cloud security model is not as mature as AWS, but AWS has been called overwhelmingly complex for small businesses or teams without extensive cloud experience. Google may not have the same level of threat detection as AWS, but it can be easier to launch, and is considered less complex.

Growth could require re-tooling (congratulations)

If a company grows from a mid-sized to large company, the scale of the team managing the SCC would have to expand. The ability to tailor the reports could become insufficient as reporting and compliance demands grow. Growth may force a revisiting of if the tools are sufficient, or if in house teams and developers using different tools is the path forward. The ability and flexibility for larger companies’ cybersecurity will be different between the three platforms listed here. At this point, I would suggest a celebratory dinner before visiting what tools they may want to research/acquire/manage.

[i] Getting Started with SCC Playlist

[ii] NIST Developing Cyber-Resilient Systems

[i] Getting Started with SCC Playlist