https://artifacts.trustmarkinitiative.org/lib/tds/developer-security-architecture-and-design-_-informal-correspondence-_-description-of-additional-security-relevant-items/1.0/Developer Security Architecture And Design | Informal Correspondence | Description of Additional Security-Relevant Items1.0Defines conformance and assessment criteria for verifying that an organization requires the developer of the information system, system component, or information system service to describe the security-relevant hardware, software, and firmware mechanisms not addressed in the descriptive informal top-level specification but strictly internal to the security-relevant hardware, software, and firmware.2018-10-17T00:00:00.000Zhttps://trustmarkinitiative.org/Trustmark InitiativePRIMARYTrustmark Supporthelp@trustmarkinitiative.org555-555-5555https://trustmarkinitiative.org/Organizations that are interested in implementing or making use of digital information systems in a manner that complies with widely accepted information security standards and practices such as NIST Special Publication 800-53.Organizations that want to demonstrate that they provide and/or consume digital information services in a manner that complies with widely accepted information security standards and practices such as NIST Special Publication 800-53.Organizations and individuals that require their trusted partners' computer and information systems to comply with widely accepted information security standards and practices such as NIST Special Publication 800-53.Organizations that audit or evaluate other organizations for compliance with widely accepted information security standards and practices such as NIST Special Publication 800-53.Any organization or business entity may act as a Trustmark Provider for trustmarks under this Trustmark Definition.Any individual employed or contracted by the Trustmark Provider may act as the assessor for trustmarks under this Trustmark Definition.For any trustmark issued under this Trustmark Definition, the Trustmark Provider must revoke the trustmark upon any condition whereby one or more Conformance Criteria cease to be satisfied.This Trustmark Definition requires no extension data.This artifact is published by the Georgia Tech Research Institute (GTRI) as part of the Trustmark Initiative. This artifact and the information contained herein is provided on an "AS IS" basis, and GTRI disclaims all warranties, express or implied, including but not limited to any warranty that the use of the information herein will not infringe any rights or any implied warranties or merchantability or fitness for a particular purpose. In addition, GTRI disclaims legal liability for any loss incurred as a result of the use or reliance on the document or the information contained herein.System and Services AcquisitionSecurityInformation AssuranceNIST800-53AccreditationAuthenticationAuthorizing OfficialAvailabilityCertificationConfidentialityEnvironmentIncidentInformationInformation SecurityInformation SystemInformation TechnologyIntegrityManagement ControlsMediaOrganizationPotential ImpactRecordsRiskRisk ManagementSafeguardsSanitizationSecurity CategorySecurity ControlsSecurity PlanSecurity RequirementsSystemSystem Security PlanThreatUserVulnerabilitySP800-53R4NIST Special Publication 800-53 Revision 4, Security and Privacy Controls for Federal Information Systems and Organizations, National Institute of Standards and Technology, April 2013 (Includes updates as of 01-15-2014). Available at <a href="http://dx.doi.org/10.6028/NIST.SP.800-53r4">http://dx.doi.org/10.6028/NIST.SP.800-53r4</a>.
Similarly, if the criteria specify a "Selection" among multiple options (e.g. [Selection (one or more): as needed; ]), the option(s) implemented by the organization must also be defined and documented.]]>1C1The organization requires the developer of the information system, system component, or information system service to:
(a) Produce, as an integral part of the development process, an informal descriptive top-level specification that specifies the interfaces to security-relevant hardware, software, and firmware in terms of exceptions, error messages, and effects;
(b) Show via [Selection: informal demonstration, convincing argument with formal methods as feasible] that the descriptive top-level specification is consistent with the formal policy model;
(c) Show via informal demonstration, that the descriptive top-level specification completely covers the interfaces to security-relevant hardware, software, and firmware;
(d) Show that the descriptive top-level specification is an accurate description of the interfaces to security-relevant hardware, software, and firmware; and
(e) Describe the security-relevant hardware, software, and firmware mechanisms not addressed in the descriptive top-level specification but strictly internal to the security-relevant hardware, software, and firmware.Appendix F, SA-17 (4)]]>
Similarly, if a "Selection" among multiple options (e.g. [Selection (one or more): as needed; ]) is specified, evidence must be provided to establish that the option(s) implemented by the organization have been defined and documented.
The assessment step shall not be marked as satisfied without this evidence.]]>1Developer Security Architecture And Design | Informal Correspondence | Description of Additional Security-Relevant ItemsDoes the organization require the developer of the information system, system component, or information system service to describe the security-relevant hardware, software, and firmware mechanisms not addressed in the descriptive informal top-level specification but strictly internal to the security-relevant hardware, software, and firmware?A1