本节简要描述了 CC 安全功能需求（按 CC 类别），主要目的是让您了解您可能希望在软件中包含的安全需求类型。如果您想了解有关 CC 需求的更多详细信息，请参阅 CC 第 2 部分。以下是 CC 安全需求的主要类别，以及该类别的 3 个字母的 CC 缩写
安全审计 (FAU)。也许您需要识别、记录、存储和分析与安全相关的活动。您需要确定您希望审计什么，因为通常您不能启用所有可能的审计功能。此外，请考虑在没有审计空间时该怎么办 - 如果您停止系统，攻击者可能会故意执行会被记录的事情，从而停止系统。
通信/不可否认性 (FCO)。这个类别在 CC 中命名不佳；官方名称是通信，但真正的含义是不可否认性。发起人不能否认发送过消息，或者接收者不能否认收到过消息，这是否重要？技术本身对不可否认性的支持是有限的（例如，如果用户希望以后能够否认某些事情，他们可能会提前泄露他们的私钥），但尽管如此，对于某些应用程序来说，支持不可否认性功能非常有用。
密码学支持 (FCS)。如果您正在使用密码学，那么哪些操作使用密码学，您正在使用哪些算法和密钥大小，以及您如何管理它们的密钥（包括分发和销毁）？
用户数据保护 (FDP)。此类规定了保护用户数据的要求，是 CC 中的一个大类，其中包含许多子类。基本思想是您应该为数据指定策略（访问控制或信息流规则），开发各种方法来实现该策略，可能支持离线存储、导入和导出，并在 TOE 之间传输用户数据时提供完整性。一个经常被遗忘的问题是残留信息保护 - 如果攻击者稍后可以恢复“已删除”的数据，这是否可以接受？
身份识别和身份验证 (FIA)。通常，您不只是希望用户报告他们是谁（身份识别） - 您需要验证他们的身份，这个过程称为身份验证。密码是最常见的身份验证机制。通常，限制身份验证尝试的次数（如果可以）并限制身份验证期间的反馈（例如，显示星号而不是实际密码）是很有用的。当然，限制用户在身份验证之前可以执行的操作；在许多情况下，在没有身份验证的情况下，不要让用户执行任何操作。可能会有很多问题控制会话何时可以开始，但在 CC 世界中，这由下面描述的“TOE 访问” (FTA) 类处理。
安全管理 (FMT)。许多系统都需要某种形式的管理（例如，控制谁可以做什么），通常由那些被赋予更受信任角色（例如，管理员）的人员进行。请务必仔细考虑这些特殊操作是什么，并确保只有具有受信任角色的人员才能调用它们。您想要限制信任；理想情况下，即使是更受信任的角色也应该在他们可以做什么方面受到限制。
隐私 (FPR)。您是否需要支持匿名性、假名性、不可链接性或不可观察性？如果是这样，是否有您想要或不想要这些功能的条件（例如，管理员是否应该能够确定隐藏在假名背后的人的真实身份？）。请注意，如果您也想要不可否认性，这些功能可能会与不可否认性严重冲突。如果您担心复杂的威胁，这些功能可能很难提供。
TOE 安全功能保护/自我保护 (FPT)。显然，如果 TOE 可以被破坏，那么它提供的任何安全功能都是没有价值的，并且在许多情况下，TOE 必须提供至少一些自我保护。也许您应该“测试底层的抽象机” - 即，测试底层组件是否满足您的假设，或者让产品运行自检（例如在启动期间、定期或按需）。您可能应该“安全失效”，至少在某些条件下；确定这些条件是什么。考虑 TOE 的物理保护。您可能需要在发生故障后提供某种安全恢复功能。拥有重放检测（检测攻击者何时尝试重放旧的操作）并对抗它是很有用的。通常，TOE 必须确保在执行受限操作之前始终调用并实际成功执行任何访问检查。
资源利用 (FRU)。也许您需要提供容错、服务优先级方案或支持资源分配（例如配额系统）。
TOE 访问 (FTA)。可能有很多问题控制会话。也许应该限制并发会话的数量（如果您正在运行 Web 服务，同一用户同时登录，或从两台不同的机器登录是否有意义？）。也许您应该自动锁定或终止会话（例如，在超时后），或者让用户启动会话锁定。您可能想要包含一个标准的警告横幅。一个非常有用信息是，在登录时显示有关上次会话的信息（例如，上次登录的日期/时间和位置）以及上次不成功的尝试的日期/时间 - 这为用户提供了可以帮助他们检测闯入者的信息。也许会话只能根据其他标准建立（例如，也许您只能在工作时间使用该程序）。
可信路径/通道 (FTP)。攻击者使用的一个常见技巧是使屏幕看起来不像它实际的样子，例如，运行一个看起来像登录屏幕的普通程序或伪造的网站。因此，也许需要一个“可信路径” - 用户可以确保他们正在与“真正的”程序对话的一种方式。