88 lines
5.1 KiB
Markdown
88 lines
5.1 KiB
Markdown
# Agent Guidance: Organizational Policies Repository
|
||
|
||
## Project Overview
|
||
|
||
This repository is **not a software project**. It is a documentation repository that serves as the single source of truth for official organizational policies. All content is written in Markdown and version-controlled with Git.
|
||
|
||
- **Repository root:** `/Users/avedelphina/Local/policies`
|
||
- **Primary language:** English (all documents and metadata are in English)
|
||
- **Content format:** Markdown (`.md`)
|
||
- **Version control:** Git
|
||
- **License / confidentiality:** All content is confidential and for internal organizational use only. All rights reserved.
|
||
|
||
The repository currently contains one policy category:
|
||
|
||
- **`Security/`** — Information security, authentication, password, and identity-management policies and implementation guidance.
|
||
|
||
No application code, build artifacts, package managers, or runtime environments are present.
|
||
|
||
## Repository Structure
|
||
|
||
```
|
||
.
|
||
├── README.md # Human-facing project description and contribution guidelines
|
||
├── .gitignore # Ignores .DS_Store only
|
||
└── Security/
|
||
├── authentication_guidance.md # Practical hardening guidance for authentication
|
||
├── authentication_policy.md # Normative authentication policy (AALs, MFA, session management)
|
||
├── password_guidance_generic.md # System-agnostic password implementation guidance
|
||
├── password_guidance_m365_ad.md # Microsoft 365 / AD password guidance (marked as Draft)
|
||
├── password_policy_generic.md # System-agnostic password and authenticator policy
|
||
└── password_policy_m365_ad.md # Microsoft 365 / AD password and authenticator policy
|
||
```
|
||
|
||
## Technology Stack
|
||
|
||
- **Markup:** GitHub-flavored Markdown
|
||
- **Tooling:** Plain text editors and Git; no compilers, interpreters, linters, or package managers are configured
|
||
- **No build system:** There is no `pyproject.toml`, `package.json`, `Cargo.toml`, `Makefile`, `setup.py`, CI/CD configuration, or equivalent
|
||
- **No runtime architecture:** This repository produces human-readable policy documents, not an executable application or service
|
||
|
||
## Document Conventions
|
||
|
||
When editing or adding policy documents, follow the conventions already established in the existing files:
|
||
|
||
1. **Header metadata block** — Begin each policy or guidance document with:
|
||
```markdown
|
||
**Document owner:** [Owner/Role]
|
||
**Approved by:** [Steering Committee / CISO]
|
||
**Effective date:** [YYYY-MM-DD]
|
||
**Review cadence:** [Annually]
|
||
```
|
||
2. **Section numbering** — Use decimal heading numbers (`## 1. …`, `### 2.1 …`) for policy documents; guidance documents may use either decimal or bracketed numbers (`## 1) …`).
|
||
3. **Organization placeholder** — Use `[Organization]` where the company name should appear.
|
||
4. **Normative language** — Policy documents use RFC-style keywords such as **must**, **shall**, **should**, **may**, and **prohibited**. Guidance documents use **should**, **recommend**, and **consider**.
|
||
5. **References** — Cite authoritative sources in a final `## References` section. Commonly referenced standards include:
|
||
- NIST SP 800-63B (Digital Identity Guidelines)
|
||
- CIS Controls v8.1
|
||
- ENISA Digital Identity and Data Protection guidance
|
||
- OWASP Authentication Cheat Sheet
|
||
- Microsoft Security Baselines for Windows / M365 / AD
|
||
6. **Tables and checklists** — Use Markdown tables for matrix requirements (e.g., account type × AAL, TLP sensitivity × AAL) and emoji checkboxes (`✅`) for hardening checklists.
|
||
7. **Draft status** — If a document is not yet approved, append `(Draft)` to its title.
|
||
|
||
## Build and Test Commands
|
||
|
||
There are no build, test, or deploy commands for this repository. Changes are validated through:
|
||
|
||
- Markdown rendering preview
|
||
- Manual editorial and legal/policy review
|
||
- Pull-request review by the policy management team
|
||
|
||
## Contribution and Review Workflow
|
||
|
||
1. Create a feature branch for any change.
|
||
2. Edit or add Markdown policy documents using the conventions above.
|
||
3. Open a pull request describing the proposed updates.
|
||
4. The policy management team reviews and merges approved changes.
|
||
|
||
All contributions must align with organizational goals and legal requirements. Do not commit generated build artifacts, temporary files, or `.DS_Store` files.
|
||
|
||
## Security Considerations
|
||
|
||
- The repository content itself defines security requirements; treat the files as sensitive organizational records.
|
||
- Do not embed secrets, credentials, or private individual data in any Markdown file.
|
||
- Keep placeholder fields (`[Owner/Role]`, `[YYYY-MM-DD]`, `[Organization]`) until they are formally populated by the policy owner.
|
||
- Maintain consistency across related policies. For example, password length requirements (15 characters single-factor, 8 characters with MFA, 64-character maximum) and MFA baselines should remain aligned between the Authentication Policy, Password Policy (generic), and Password Policy (M365 + AD).
|
||
- Any exception to policy requirements must be documented with compensating controls, CISO approval, and a review date not exceeding 12 months.
|