编码员征服安全。分享与学习系列--日志和监控不足
当我们在这些博客中探索主题时，我们发现了不少危险的漏洞和黑客用来攻击网络和绕过防御的恶意漏洞。它们的范围很广，从利用编程语言的弱点，到使用各种格式注入代码，再到劫持传输中的数据。这是一个相当大的威胁范围，但每当它们中的任何一个成功，往往有一个共同的组件在其受害者的应用程序中共享。
记录和监控不足是一个应用程序的防御结构中可能存在的最危险的条件之一。如果这个漏洞或条件存在，那么几乎所有针对它的高级攻击最终都会成功。记录和监控不足意味着攻击或试图攻击在很长一段时间内都不会被发现，如果有的话。这基本上给了攻击者找到一个有用的漏洞并加以利用的时间。
在这一集里，我们将学习。
- 攻击者如何利用不充分的记录和监控
- 为什么记录和监控不足是危险的
- 可以修复这个漏洞的技术。
攻击者如何利用不充分的记录和监控？
起初，攻击者不知道一个系统是否被适当监控，或者日志文件是否被检查出可疑的活动。但他们很容易就能发现。他们有时会做的是发起某种形式的低级、蛮力式的攻击，也许是查询用户数据库的常用密码。然后他们等上几天，再次尝试同样的攻击方式。如果他们第二次没有被阻止，那么这就很好地表明，没有人仔细监测日志文件中的可疑活动。
即使测试一个应用程序的防御系统和衡量发生的主动监测水平相对简单，但这不是成功的攻击的要求。他们可以简单地以这样的方式发起攻击，以尽可能少地发出声音。更多的时候，太多的警报、警报疲劳、糟糕的安全配置或仅仅是大量可利用的漏洞的组合意味着他们将有足够的时间在防御者甚至意识到他们存在之前完成他们的目标。
为什么日志和监控不足是危险的？
不充分的记录和监控是危险的，因为它不仅给了攻击者时间来发动他们的攻击，而且在防御者能够启动响应之前很久完成他们的目标。多少时间取决于被攻击的网络，但像开放网络应用安全项目（OWASP）这样的不同团体认为被攻破的网络的平均响应时间为191天或更长。
想一想这个问题。如果劫匪劫持了一家银行，人们打电话给警察，而他们花了半年时间才作出反应，会发生什么？
当警察到达时，劫匪早已离开。事实上，在警察对第一起事件作出反应之前，同一家银行可能还会被抢劫很多次。
在网络安全方面也是如此。你在新闻中听到的大多数高调的违规事件都不是打砸抢式的行动。通常情况下，目标组织只有在攻击者或多或少地完全控制了数据数月甚至数年之后，才会了解到入侵事件。这使得记录和监控不足成为在试图实践良好的网络安全时可能发生的最危险情况之一。
消除不充分的记录和监控
防止不充分的记录和监控需要两个主要方面。首先，所有的应用程序都必须具备监控和记录服务器端输入验证失败的能力，并有足够的用户背景，以便安全团队识别攻击者正在使用的工具和技术，如果不是用户账户的话。或者，这种输入应该被格式化为STIX（结构化威胁信息表达）这样的语言，可以被安全工具快速处理以产生适当的警报。
其次，仅仅产生良好的警报是不够的，尽管这是一个开始。企业还需要建立角色和责任，以便及时调查这些警报。许多成功的入侵事件实际上触发了被攻击网络的警报，但由于责任问题，这些警报没有被注意到。没有人知道谁的工作是回应，或假设其他人正在调查这个问题。
在分配责任时，一个好的开始是采用一个事件响应和恢复计划，如国家标准与技术研究所（NIST）在特别出版物800-61中推荐的计划。还有其他的参考文件，包括针对不同行业的文件，它们不一定要被完全遵循。但是，形成一个计划，确定组织内谁对警报作出反应，以及他们如何及时作出反应，是至关重要的。
关于日志和监控不足的更多信息
要进一步阅读，你可以看看OWASP对记录和监控不足的看法。你也可以用Secure Code Warrior 平台的免费演示来测试你新发现的防御知识，该平台培训网络安全团队成为终极网络战士。要了解更多关于击败这个漏洞以及其他威胁的流氓画廊，请访问Secure Code Warrior 博客。
准备好现在就发现、修复和消除日志和监控的不足了吗？前往我们的培训场。 [从这里开始]
Jaap Karan Singh是一位安全编码布道者，首席辛格和Secure Code Warrior 的共同创始人。
Secure Code Warrior 我们在这里为您的组织提供服务，帮助您在整个软件开发生命周期中确保代码安全，并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人，我们都可以帮助您的组织减少与不安全代码有关的风险。
预定一个演示
Jaap Karan Singh是一位安全编码布道者，首席辛格和Secure Code Warrior 的共同创始人。
当我们在这些博客中探索主题时，我们发现了不少危险的漏洞和黑客用来攻击网络和绕过防御的恶意漏洞。它们的范围很广，从利用编程语言的弱点，到使用各种格式注入代码，再到劫持传输中的数据。这是一个相当大的威胁范围，但每当它们中的任何一个成功，往往有一个共同的组件在其受害者的应用程序中共享。
记录和监控不足是一个应用程序的防御结构中可能存在的最危险的条件之一。如果这个漏洞或条件存在，那么几乎所有针对它的高级攻击最终都会成功。记录和监控不足意味着攻击或试图攻击在很长一段时间内都不会被发现，如果有的话。这基本上给了攻击者找到一个有用的漏洞并加以利用的时间。
在这一集里，我们将学习。
- 攻击者如何利用不充分的记录和监控
- 为什么记录和监控不足是危险的
- 可以修复这个漏洞的技术。
攻击者如何利用不充分的记录和监控？
起初，攻击者不知道一个系统是否被适当监控，或者日志文件是否被检查出可疑的活动。但他们很容易就能发现。他们有时会做的是发起某种形式的低级、蛮力式的攻击，也许是查询用户数据库的常用密码。然后他们等上几天，再次尝试同样的攻击方式。如果他们第二次没有被阻止，那么这就很好地表明，没有人仔细监测日志文件中的可疑活动。
即使测试一个应用程序的防御系统和衡量发生的主动监测水平相对简单，但这不是成功的攻击的要求。他们可以简单地以这样的方式发起攻击，以尽可能少地发出声音。更多的时候，太多的警报、警报疲劳、糟糕的安全配置或仅仅是大量可利用的漏洞的组合意味着他们将有足够的时间在防御者甚至意识到他们存在之前完成他们的目标。
为什么日志和监控不足是危险的？
不充分的记录和监控是危险的，因为它不仅给了攻击者时间来发动他们的攻击，而且在防御者能够启动响应之前很久完成他们的目标。多少时间取决于被攻击的网络，但像开放网络应用安全项目（OWASP）这样的不同团体认为被攻破的网络的平均响应时间为191天或更长。
想一想这个问题。如果劫匪劫持了一家银行，人们打电话给警察，而他们花了半年时间才作出反应，会发生什么？
当警察到达时，劫匪早已离开。事实上，在警察对第一起事件作出反应之前，同一家银行可能还会被抢劫很多次。
在网络安全方面也是如此。你在新闻中听到的大多数高调的违规事件都不是打砸抢式的行动。通常情况下，目标组织只有在攻击者或多或少地完全控制了数据数月甚至数年之后，才会了解到入侵事件。这使得记录和监控不足成为在试图实践良好的网络安全时可能发生的最危险情况之一。
消除不充分的记录和监控
防止不充分的记录和监控需要两个主要方面。首先，所有的应用程序都必须具备监控和记录服务器端输入验证失败的能力，并有足够的用户背景，以便安全团队识别攻击者正在使用的工具和技术，如果不是用户账户的话。或者，这种输入应该被格式化为STIX（结构化威胁信息表达）这样的语言，可以被安全工具快速处理以产生适当的警报。
其次，仅仅产生良好的警报是不够的，尽管这是一个开始。企业还需要建立角色和责任，以便及时调查这些警报。许多成功的入侵事件实际上触发了被攻击网络的警报，但由于责任问题，这些警报没有被注意到。没有人知道谁的工作是回应，或假设其他人正在调查这个问题。
在分配责任时，一个好的开始是采用一个事件响应和恢复计划，如国家标准与技术研究所（NIST）在特别出版物800-61中推荐的计划。还有其他的参考文件，包括针对不同行业的文件，它们不一定要被完全遵循。但是，形成一个计划，确定组织内谁对警报作出反应，以及他们如何及时作出反应，是至关重要的。
关于日志和监控不足的更多信息
要进一步阅读，你可以看看OWASP对记录和监控不足的看法。你也可以用Secure Code Warrior 平台的免费演示来测试你新发现的防御知识，该平台培训网络安全团队成为终极网络战士。要了解更多关于击败这个漏洞以及其他威胁的流氓画廊，请访问Secure Code Warrior 博客。
准备好现在就发现、修复和消除日志和监控的不足了吗？前往我们的培训场。 [从这里开始]
当我们在这些博客中探索主题时，我们发现了不少危险的漏洞和黑客用来攻击网络和绕过防御的恶意漏洞。它们的范围很广，从利用编程语言的弱点，到使用各种格式注入代码，再到劫持传输中的数据。这是一个相当大的威胁范围，但每当它们中的任何一个成功，往往有一个共同的组件在其受害者的应用程序中共享。
记录和监控不足是一个应用程序的防御结构中可能存在的最危险的条件之一。如果这个漏洞或条件存在，那么几乎所有针对它的高级攻击最终都会成功。记录和监控不足意味着攻击或试图攻击在很长一段时间内都不会被发现，如果有的话。这基本上给了攻击者找到一个有用的漏洞并加以利用的时间。
在这一集里，我们将学习。
- 攻击者如何利用不充分的记录和监控
- 为什么记录和监控不足是危险的
- 可以修复这个漏洞的技术。
攻击者如何利用不充分的记录和监控？
起初，攻击者不知道一个系统是否被适当监控，或者日志文件是否被检查出可疑的活动。但他们很容易就能发现。他们有时会做的是发起某种形式的低级、蛮力式的攻击，也许是查询用户数据库的常用密码。然后他们等上几天，再次尝试同样的攻击方式。如果他们第二次没有被阻止，那么这就很好地表明，没有人仔细监测日志文件中的可疑活动。
即使测试一个应用程序的防御系统和衡量发生的主动监测水平相对简单，但这不是成功的攻击的要求。他们可以简单地以这样的方式发起攻击，以尽可能少地发出声音。更多的时候，太多的警报、警报疲劳、糟糕的安全配置或仅仅是大量可利用的漏洞的组合意味着他们将有足够的时间在防御者甚至意识到他们存在之前完成他们的目标。
为什么日志和监控不足是危险的？
不充分的记录和监控是危险的，因为它不仅给了攻击者时间来发动他们的攻击，而且在防御者能够启动响应之前很久完成他们的目标。多少时间取决于被攻击的网络，但像开放网络应用安全项目（OWASP）这样的不同团体认为被攻破的网络的平均响应时间为191天或更长。
想一想这个问题。如果劫匪劫持了一家银行，人们打电话给警察，而他们花了半年时间才作出反应，会发生什么？
当警察到达时，劫匪早已离开。事实上，在警察对第一起事件作出反应之前，同一家银行可能还会被抢劫很多次。
在网络安全方面也是如此。你在新闻中听到的大多数高调的违规事件都不是打砸抢式的行动。通常情况下，目标组织只有在攻击者或多或少地完全控制了数据数月甚至数年之后，才会了解到入侵事件。这使得记录和监控不足成为在试图实践良好的网络安全时可能发生的最危险情况之一。
消除不充分的记录和监控
防止不充分的记录和监控需要两个主要方面。首先，所有的应用程序都必须具备监控和记录服务器端输入验证失败的能力，并有足够的用户背景，以便安全团队识别攻击者正在使用的工具和技术，如果不是用户账户的话。或者，这种输入应该被格式化为STIX（结构化威胁信息表达）这样的语言，可以被安全工具快速处理以产生适当的警报。
其次，仅仅产生良好的警报是不够的，尽管这是一个开始。企业还需要建立角色和责任，以便及时调查这些警报。许多成功的入侵事件实际上触发了被攻击网络的警报，但由于责任问题，这些警报没有被注意到。没有人知道谁的工作是回应，或假设其他人正在调查这个问题。
在分配责任时，一个好的开始是采用一个事件响应和恢复计划，如国家标准与技术研究所（NIST）在特别出版物800-61中推荐的计划。还有其他的参考文件，包括针对不同行业的文件，它们不一定要被完全遵循。但是，形成一个计划，确定组织内谁对警报作出反应，以及他们如何及时作出反应，是至关重要的。
关于日志和监控不足的更多信息
要进一步阅读，你可以看看OWASP对记录和监控不足的看法。你也可以用Secure Code Warrior 平台的免费演示来测试你新发现的防御知识，该平台培训网络安全团队成为终极网络战士。要了解更多关于击败这个漏洞以及其他威胁的流氓画廊，请访问Secure Code Warrior 博客。
准备好现在就发现、修复和消除日志和监控的不足了吗？前往我们的培训场。 [从这里开始]
当我们在这些博客中探索主题时，我们发现了不少危险的漏洞和黑客用来攻击网络和绕过防御的恶意漏洞。它们的范围很广，从利用编程语言的弱点，到使用各种格式注入代码，再到劫持传输中的数据。这是一个相当大的威胁范围，但每当它们中的任何一个成功，往往有一个共同的组件在其受害者的应用程序中共享。
记录和监控不足是一个应用程序的防御结构中可能存在的最危险的条件之一。如果这个漏洞或条件存在，那么几乎所有针对它的高级攻击最终都会成功。记录和监控不足意味着攻击或试图攻击在很长一段时间内都不会被发现，如果有的话。这基本上给了攻击者找到一个有用的漏洞并加以利用的时间。
在这一集里，我们将学习。
- 攻击者如何利用不充分的记录和监控
- 为什么记录和监控不足是危险的
- 可以修复这个漏洞的技术。
攻击者如何利用不充分的记录和监控？
起初，攻击者不知道一个系统是否被适当监控，或者日志文件是否被检查出可疑的活动。但他们很容易就能发现。他们有时会做的是发起某种形式的低级、蛮力式的攻击，也许是查询用户数据库的常用密码。然后他们等上几天，再次尝试同样的攻击方式。如果他们第二次没有被阻止，那么这就很好地表明，没有人仔细监测日志文件中的可疑活动。
即使测试一个应用程序的防御系统和衡量发生的主动监测水平相对简单，但这不是成功的攻击的要求。他们可以简单地以这样的方式发起攻击，以尽可能少地发出声音。更多的时候，太多的警报、警报疲劳、糟糕的安全配置或仅仅是大量可利用的漏洞的组合意味着他们将有足够的时间在防御者甚至意识到他们存在之前完成他们的目标。
为什么日志和监控不足是危险的？
不充分的记录和监控是危险的，因为它不仅给了攻击者时间来发动他们的攻击，而且在防御者能够启动响应之前很久完成他们的目标。多少时间取决于被攻击的网络，但像开放网络应用安全项目（OWASP）这样的不同团体认为被攻破的网络的平均响应时间为191天或更长。
想一想这个问题。如果劫匪劫持了一家银行，人们打电话给警察，而他们花了半年时间才作出反应，会发生什么？
当警察到达时，劫匪早已离开。事实上，在警察对第一起事件作出反应之前，同一家银行可能还会被抢劫很多次。
在网络安全方面也是如此。你在新闻中听到的大多数高调的违规事件都不是打砸抢式的行动。通常情况下，目标组织只有在攻击者或多或少地完全控制了数据数月甚至数年之后，才会了解到入侵事件。这使得记录和监控不足成为在试图实践良好的网络安全时可能发生的最危险情况之一。
消除不充分的记录和监控
防止不充分的记录和监控需要两个主要方面。首先，所有的应用程序都必须具备监控和记录服务器端输入验证失败的能力，并有足够的用户背景，以便安全团队识别攻击者正在使用的工具和技术，如果不是用户账户的话。或者，这种输入应该被格式化为STIX（结构化威胁信息表达）这样的语言，可以被安全工具快速处理以产生适当的警报。
其次，仅仅产生良好的警报是不够的，尽管这是一个开始。企业还需要建立角色和责任，以便及时调查这些警报。许多成功的入侵事件实际上触发了被攻击网络的警报，但由于责任问题，这些警报没有被注意到。没有人知道谁的工作是回应，或假设其他人正在调查这个问题。
在分配责任时，一个好的开始是采用一个事件响应和恢复计划，如国家标准与技术研究所（NIST）在特别出版物800-61中推荐的计划。还有其他的参考文件，包括针对不同行业的文件，它们不一定要被完全遵循。但是，形成一个计划，确定组织内谁对警报作出反应，以及他们如何及时作出反应，是至关重要的。
关于日志和监控不足的更多信息
要进一步阅读，你可以看看OWASP对记录和监控不足的看法。你也可以用Secure Code Warrior 平台的免费演示来测试你新发现的防御知识，该平台培训网络安全团队成为终极网络战士。要了解更多关于击败这个漏洞以及其他威胁的流氓画廊，请访问Secure Code Warrior 博客。
准备好现在就发现、修复和消除日志和监控的不足了吗？前往我们的培训场。 [从这里开始]
资源
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
安全代码培训主题和内容
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peek of what our content catalog has to offer by topic and role.
资源
Observe and Secure the ADLC: A Four-Point Framework for CISOs and Development Teams Using AI
While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.
