最近关于我们在网络安全方面遇到的一些关于利基问题（“利基问题”指的是特定领域内的独特或小众问题。这些问题通常不被广泛关注，但在特定行业或细分市场中具有重要影响。）的讨论。风险投资模式专注于可大规模赢利的市场，而这些问题并不符合投资标准。这导致安全工程师每次加入新公司时都需要在内部解决相同的非差异化问题，因为没有“购买”的替代方案。
许多其他领域的市场上都有一系列完善的小型工具，通常由小公司、个人创业者和兼职者打造。如果看看市场营销或销售等行业，就会发现一个由 SaaS 应用程序、Chrome 浏览器扩展、Excel 连接器等组成的名副其实的生态系统。
微型 SaaS 世界正在发展壮大，如今甚至出现了一个由加速器组成的生态系统帮助微型 SaaS 公司起步，并将它们出售给收购方。然而，在这个生态系统中很少能找到安全公司，原因很简单--风险。
对小型网络安全公司的不利因素往往很多，如：
-
安全工具是一个高风险领域
-
所需的安全基线需要前期投资
-
这导致采购流程更慢、更繁琐的采购流程
-
风险规避型买家更倾向于内部处理
-
缺乏可用资金来帮助小型企业克服初期障碍
自力更生型厂商成功案例
网络安全市场确实有许多厂商在解决这些较小的问题，但它们往往聚集在服务企业中，如托管安全服务提供商（MSSP）、渗透测试公司和安全咨询公司。
即使我们忽略这些领域，仍有一些公司设法打破困境，自己在市场上找到了一席之地，但这样的公司屈指可数。自力更生的成功案例包括Thinkst Canary、PortSwigger和AssetNote等公司。
这些公司显示出一种趋势：当产品不需要敏感数据或可以分割时，自力更生更型的企业更为可行。这使得创始人能够规避许多风险。
安全团队五个可解决的问题
这里想举例说明一些我们多次遇到的例子。这些问题我们最终要么在内部解决，要么只能接受风险（我们当然不希望这样做）。
下游人力资源信息系统的影响
像Workday、Rippling和Personio这样的HRIS厂商是大多数公司员工信息的真实来源。其他系统，特别是身份提供商如Okta，依赖于它们包含的信息。人力资源是一个复杂的领域，通常会发生快速变化，例如收购、新国家和组织结构变化。这些变化通常是手动完成的，或通过导入手工制作的CSV等损失过程完成。
这些变化的同时往往没有考虑到对其他系统的下游影响，这可能会造成大规模混乱。在这方面，已经出现了太多起类似的事件，从一个小变化导致的取消了所有人的访问权限，到另一个小变化导致所有工程师访问生产系统的权限等等。
有些地方也曾试图在内部解决这个问题：
-
在人力资源信息系统的基础上建立一个 terraform 层（指使用 Terraform 工具构建的基础设施管理层，用于定义、配置和管理基础设施资源，确保一致性和可重复性。），这通常很笨重，会降低工作效率，或者
-
有一些系统可以跨多个系统连接属性，警告HR他们将造成的下游影响，或者
-
建立和依靠 "干运行 "能力，并实施紧急制动率限制
据我们所知，这个问题还没有任何狭义的厂商解决方案，因为它涉及公司中最敏感的系统，而且可能还没有大到足以让公司为此支付大笔费用的地步。此外，该领域的每个厂商都会声称自己的产品不会出现这些问题。
端点漏洞自动化
EDR 工具能够让您从端点获取漏洞数据，MDM 能够更新软件包，但通常没有简单的方法将这些东西结合在一起。Canva 写了一个很好的例子，分享了他们在内部建立了什么机制来丰富数据集并提供信息，这是一个很好的开始，除此之外，自动修复策略也应该被考虑到。
用户通知/安全 Slack运维
现代 "无 SOC "安全运营计划通常依赖与终端用户的互动来丰富或确认各种警报。这可以追溯到十年前的 Square、Slack 和 Dropbox。自动化领域的 SOAR 工具让这一切变得更容易，但这仍然需要在SOAR平台上进行大量的投资和实施工作。。我们曾多次看到安全团队从零开始或通过 SOAR 工具建立了一个通信机器人，用于结合警报进行基本的用户互动。SOAR 工具的灵活性令人惊叹，但团队往往只想要一个易于部署的机器人，并能将其与所有安全警报基础架构连接起来。
无差别检测和规则
许多大型安全组织都有检测工程团队，这些团队通常都会构建相同的基本警报。检测工程团队和平台工程团队一样，应该把时间花在解决组织特有的问题上。不能再一而再、再而三地构建 "文件被传输到 U 盘 "的检测。这其中有很多注意事项，包括厂商的异质性，但大多数公司使用的都是同样的几种工具。
现在有很多开源共享可以帮助缓解这一问题，还有很多承包公司拥有大量预建检测程序，但没有理由不建立一个可点击部署的检测程序库。这些检测可以跨越多个领域，包括典型的 SIEM 检测，也包括像 SAST 这样的检测。在这个问题上，虽然确实有托管服务提供商提供这个服务，但没有一个现成的产品可以使用。
云访问和凭证管理
大量使用云的公司最终都需要在云提供商认证流程之上增加一个额外的工具层。这就为企业功能铺平了道路，如密钥库中的安全存储、轻松入职、同构多云支持、配置文件和会话管理以及众多开发人员体验改进。它还扩展到其他资源，使员工能够轻松访问服务器和 Kubernetes 集群等云资源。
我们发现这个例子很有趣，因为在这个领域，有人曾试图将开源软件商业化，比如 Noovolari（最近关闭了）。与用户通知一样，它也可以作为大型云访问平台的一个组成部分。不过，如果不是因为初创公司受到种种限制，那么专注于访问人体工程学的狭义厂商产品将在许多云安全项目中占有一席之地：这涉及到公司的 "皇冠上的宝石"，而且可能还没有大到足以让公司为其支付大笔费用的程度。
情况有所好转吗？
毫无疑问，在安全领域创办小企业是一项艰巨的任务。事实上，网络安全行业的工资很高，这也意味着人们没有太大的动力去做那些从长远来看只有很小机会增加收入的冒险事业。
采购团队每年都有更严格的要求，填写冗长的调查问卷是当今环境的常态。再加上安全团队规避风险的天性，你就会明白为什么这个领域的小企业不多了。
尽管如此，创建一家安全的公司变得越来越容易。云原生设计为安全带来了福音，它消除了过去的许多障碍，使 "默认安全"（security-by-default）成为新服务启动时的规范。如今，我们经常可以看到初创公司在几个员工和几个月的时间内，就可以拿到 SOC 2（SOC 2 是一份评估报告，验证服务提供商在数据安全性、可用性、处理完整性、机密性和隐私性方面的合规性和控制措施。）。
一个有趣的讽刺是，新企业可能比许多传统企业更安全。看看过去几年的大型公开漏洞，你会发现现实生活中的攻击通常是基本的网络钓鱼、凭证盗窃或传统基础设施的破坏。拥有安全密钥、无密码、Chromebook 和无传统基础设施的小型企业在安全性方面会远远领先于昨天的企业，只是他们没有所需的文件和证明来支持而已。
开源能解决这个问题吗？
开源无疑会有所帮助，但终究不是灵丹妙药，Osquery（一个开源的操作系统监控工具，允许用户通过SQL查询获取系统状态和性能数据。） 就是一个很好的例子。
很多人（包括我们自己）都部署了 osquery 来用于端点可视化，并发现它非常有用，但管理和维护这个项目可能是个难题。包括 Fleet 和 Kolide 等公司在内的整个行业都在努力简化 osquery 的部署和管理。
许多安全团队规模较小，几乎抽不出资源来关注一个工具，更不用说跨多个平台部署和维护内部软件了。这意味着他们甚至不具备首先部署该软件的工程技能，这也是阻碍该软件更广泛应用的另一个因素。
结论
说了这么多，我们该如何减少问题，帮助小公司开始网络安全工作呢？
-
正视我们对小公司的偏见。今天的初创公司，如果管理得当，已经领先于许多企业。是的，小团队可能无法快速响应或配备专门的安全人员，这始终是一个可靠性风险，但真正的漏洞是由于人和传统基础设施造成的，而这两者都可以由一个知道自己在做什么的小团队更容易地管理。
-
从合规转向主动安全。与其实施造成不平等竞争环境的最低安全基线，不如转向积极主动的合作、审计和测试。如果我们能在这一过程中消灭愚蠢的安全问卷，那就更好了。
-
作为一家刚起步的公司，更多需要关注数据安全和细分。访问权限越小，能控制的内容越多，就越有可能找到心甘情愿的客户。
原文链接：
https://tldrsec.com/p/sub-venture-scale-security-problems
关注「安全喵喵站」，后台回复关键词**【报告】，**即可获取网安行业研究报告精彩内容合集：
《网安供应链厂商成分分析及国产化替代指南》，《网安新兴赛道厂商速查指南》，《2023中国威胁情报订阅市场分析报告》，****《网安初创天使投资态势报告》，《全球网络安全创业加速器调研报告》，《网安创业生态图》，**《網安新興賽道廠商速查指南·港澳版》，《台湾资安市场地图》，《全球网络安全全景图》，《全球独角兽俱乐部行业全景图》，《全球网络安全创业生态图》**
**话题讨论，内容投稿，报告沟通，商务合作等，**请联系喵喵 mew@z1-sec.com。
