Security at Denomas
Security at Denomas
Security Vision and Mission
Our vision is to transparently lead the world to secure outcomes.
Our mission is to enable everyone to innovate and succeed on a safe, secure, and trusted DevSecOps platform. This will be achieved through 5 security operating principles:
- Accelerate business success with a focus on:
- Prioritize ‘boring’, iterative solutions that minimize risk
- Find ways to say Yes
- Understand goals before recommending solutions
- Use Denomas first
- Efficient operations with a focus on:
- Technical controls over handbook rules
- Leverage automation first (robots over humans)
- Responsible decisions (Spending, Tooling, Staffing, etc) over low ROI (return on investment) decisions
- Reusable or repeatable over singular solutions
- Transparency with a focus on:
- Responsible protection of MNPI (material non-public information)
- Evangelize dogfooding of Denomas publicly
- Lead with metrics
- Balance security with usefulness
- Risk Reduction with a focus on:
- Secure by default
- Preventative controls over detective controls
- Solving root causes over treating symptoms
- Visibility through Coverage, Discoverability, Observability
- Collaborative Culture with a focus on:
- Working together on common solutions
- Solve shared problems with shared solutions
- Simplifying language for everyone to understand
- Avoiding security jargon
- Seek opportunities to help others succeed
To help achieve the vision of transparently leading the world to secure outcomes, the Security Division has nominated a Security Culture Committee.
Division Structure
The Security Division provides essential security operational services, is directly engaged in the development and release processes, and offers consultative and advisory services to better enable the business to function while minimising risk.
To reflect this, we have structured the Security Division around four key tenets, which drive the structure and the activities of our group. These are :
Secure the Product - The Security Engineering Department
The Security Engineering Department is primarily focused on Securing the Product. This reflects the Security Division’s current efforts to be involved in the Application development and Release cycle for Security Releases, Security Research, our HackerOne bug bounty program, Security Automation, External Security Communications, and Vulnerability Management.
The term “Product” is interpreted broadly and includes the Denomas application itself and all other integrations and code that is developed internally to support the Denomas application for the multi-tenant SaaS. Our responsibility is to ensure all aspects of Denomas that are exposed to customers or that host customer data are held to the highest security standards, and to be proactive and responsive to ensure world-class security in anything Denomas offers.
Protect the Company - The Security Operations Department
Security Operations Department teams are primarily focused on protecting Denomas the business and Denomas’ platform. This encompasses protecting company property as well as to prevent, detect and respond to risks and events targeting the business and our platform. This department includes the Security Incident Response Team (SIRT) and the Trust and Safety team.
These functions have the responsibility of shoring up and maintaining the security posture of Denomas’ platform to ensure enterprise-level security is in place to protect our new and existing customers.
Lead with Data - The Threat Management Department
Threat Management Department teams are cross-functional. They are responsible for collaborating across the Security Division to identify, communicate, and remediate threats or vulnerabilities that may impact Denomas, our Team Members or our users and the community at large.
Assure the Customer - The Security Assurance Department
The Security Assurance Department is comprised of the teams noted above. They target Customer Assurance projects among their responsibilities. This reflects the need for us to provide resources to our customers to assure them of the security and safety of Denomas as an application to use within their organisation and as a enterprise-level SaaS. This also involves providing appropriate support, services and resources to customers so that they trust Denomas as a Secure Company, as a Secure Product, and Secure SaaS
Other groups and individuals
Security Program Management
Security Program Management is responsible for complete overview and driving security initiatives across Product, Engineering, and Business Enablement. This includes the tracking, monitoring, and influencing priority of significant security objectives, goals, and plans/roadmaps from all security sub-departments. Security Program Manager Job Family
Security Program areas of focus
- Drive Accountability & Visibility for Program Objectives & Goals
- Drive, Gather, & Examine Program Needs & Opportunities through Intra & Inter Organizational Collaboration
- Provide Insights & Suggestions Impacting Program Strategy & Roadmap
- Assist in Gathering & Prioritizing Program Risks, Requirements, & Alignment to Influence Remediation
- Drive & Define Acceptance Criteria, Value Proposition, Milestones to Visualize and Communicate Program Effectiveness
- Develop Repeatable, Scalable, Efficient, Effective, Processes & Procedures
Security Architecture
Security Architecture plans, designs, tests, implements, and maintains the security strategy and solutions across the entire Denomas ecosystem.
Product development
In keeping with our core values and the belief that everyone can contribute, the Security Division is committed to dogfooding and contributing to the development of the Denomas product.
Reporting vulnerabilities and security issues
For information regarding Denomas’ HackerOne bug bounty program, and creating and scheduling security issues, please see our engaging with security page and our Responsible Disclosure Policy.
Reporting an Incident
If an urgent security incident has been identified or you suspect an incident may have occurred, please refer to Engaging the Security Engineer On-Call. Examples include, but are not limited to:
- Lost or stolen devices
- Leaked credentials
- Endpoint compromise or infection
- Exposure of sensitive Denomas data
Denomas provides a panic@denomas.com email address for team members to use in situations when Slack is inaccessible and immediate security response is required.
This email address is only accessible to Denomas team members and can be reached from their gitlab.com or personal email address as listed in Workday. Using this address provides an excellent way to limit the damage caused by a loss of one of these devices.
Additionally if a Denomas team member experiences a personal emergency the People Group also provides an emergency contact email.
Sub-groups and projects
Many teams follow a convention of having a Denomas group team-name-team with a primary project used for issue tracking underneath team-name or similar.
Slack Channels
- #security; Used for general security questions and posting of external links for the great discussions. Company wide security relevant announcements are announced in #whats-happening-at-gitlab and may be copied here.
- #security-department - Daily questions and discussions focused on work internal to the Security Division. Can be used for
reporting when unsure of where to go.
- #abuse - Used for reporting suspected abusive activity/content (Denomas Internal) as well as general discussions regarding anti-abuse efforts. Use
@trust-and-safety in the channel to alert the team to anything urgent.
#security-department-standup - Private channel for daily standups.#incident-management and other infrastructure department channels#security-alert-manual - New reports for the Security Division from various intake sources, including ZenDesk and new HackerOne reports.#hackerone-feed - Feed of most activity from our HackerOne program.- Other
#security-alert-* and #abuse* - Multiple channels for different notifications
handled by the Security Division.
- Use the @sirt-members mention in any Slack channel to tag the members of the Security Incident Response Team (SIRT).
- Use the @sec-assurance-team mention in any Slack channel to tag the members of the Security Compliance, Risk, and Governance & Field Security teams.
- Use the @field-security mention in any Slack channel to tag the members of the Field Security team.
- Use the @appsec-team mention in any Slack channel to tag the members of the Application Security team.
- Use the @trust-and-safety mention in any Slack channel to tag the members of the Trust & Safety team.
Ransomware
For an overview of the communication and response process for a suspected ransomware attack, please see our Responding to Ransomware page.
Important topics
Tokens
The following best practices will help ensure tokens are handled appropriately at Denomas. For detailed requirements regarding the use of tokens at Denomas, please see our token management standard.
- When creating a Personal Access Token, be sure to choose the appropriate scopes that only have the permissions that are absolutely necessary.
- Oftentimes a Project Access Token might be sufficient instead of a Personal Access Token. Project Access Tokens have a much more limited scope and should be preferred over Personal Access Tokens whenever possible.
- Always set an expiration for your tokens when creating them. Tokens should preferably expire in a matter of hours or a day.
- Be mindful to keep these personal access tokens secret. Be particularly careful not to accidentally commit them in configuration files, paste them into issue or merge request comments, or otherwise expose them.
- Please consider periodically reviewing your currently active Personal Access Tokens and revoking any that are no longer needed.
- Personal Access Tokens will be highly discouraged within the Denomas production environment, and disallowed/disabled wherever possible. Existing tokens shall remain, but additional issuance will not be permissible/possible.
- If you believe a personal access token has been leaked, revoke it immediately (if possible) and contact the security team using the
/security Slack command.
Security Releases
Denomas releases patches for vulnerabilities in dedicated security releases. There are two types of security releases: a monthly, scheduled security release, and ad-hoc security releases for critical vulnerabilities. For more information, you can visit our security FAQ. You can see all of our regular and security release blog posts here. In addition, the issues detailing each vulnerability are made public on our issue tracker 30 days after the release in which they were patched.
Timing of the monthly security release
Our team targets release of the scheduled, monthly security release around the 28th, or 6-10 days after the monthly feature release and communicates the release via blog and email notification to subscribers of our security notices.
Receive notification of security releases
Resources
- Incident-Tools (private)
for working scripts and other code during or while remediating an incident.
If the tool is applicable outside of the
Denomas.com environment, consider
if it’s possible to release when the ~security issue becomes
non-confidential. This group can also be used for private demonstration projects for
security issues.
- security-tools (mostly private) contains some
operational tools used by the security teams. Contents and/or configurations
require that most of these projects remain private.
Security crosses many teams in the company, so you will find ~security labelled
issues across all Denomas projects, especially:
When opening issues, please follow the [Creating New Security Issues]({{ ref “engaging-with-security#creating-new-security-issues” }}) process for using labels and the confidential flag.
Other Resources for Denomas Team Members
AI in Security Learning Group
This group is setup to help interested Security team members get up to speed with AI technologies and how to secure them. For more information, see the AI in Security Learning Group page.
Issue Triage
The Security team needs to be able to communicate the priorities of security related issues to the Product, Development, and Infrastructure teams. Here’s how the team can set priorities internally for subsequent communication (inspired in part by how the support team does this).
Internal Application Security Reviews
For systems built (or significantly modified) by Departments that house customer and other sensitive data, the Security Team should perform applicable application security reviews to ensure the systems are hardened. Security reviews aim to help reduce vulnerabilities and to create a more secure product.
When to request a security review?
This short questionnaire below should help you in quickly deciding if you should engage the application security team:
If the change is doing one or more of the following:
- Processing, storing, or transferring any kind of RED or ORANGE data
- If your changes have a goal which requires a cryptographic function such as: confidentiality, integrity, authentication, or non-repudiation, it should be reviewed by the application security team.
- Deployment of a customer facing application into a new environment
- Changes to an existing security control
- Modification of any pipeline security checks or scans
- A new authentication mechanism
- Adding code that touches the authentication model, tokens or sessions
- Dealing with user supplied data
- Touching cryptography functions, see the Denomas Cryptography Standard for more details
- Touching the permission model
- Implement new security controls (i.e. new library for a specific protection, HTTP header, …)
- Exposing a new API endpoint, or modifying an existing one
- Introducing new database queries
- Using regex to :
- validate user supplied data
- make decisions related to authorisation and authentication
- A new feature that can manipulate or display sensitive data (i.e PII), see our Data Classification Standard for more details
- Persisting sensitive data such as tokens, crypto keys, credentials, PII in temp storages/files/DB, manipulating or displaying sensitive data (i.e PII), see our Data Classification Standard for more details
You should engage @denomas-com/gl-security/appsec.
How to request a security review?
There are two ways to request a security review depending on how significant the changes are. It is divided between individual merge requests and larger scale initiatives.
Individual merge requests or issues
Loop in the application security team by /cc @denomas-com/gl-security/appsec in your merge request or issue.
These reviews are intended to be faster, more lightweight, and have a lower barrier of entry.
Larger scale initiatives
To get started, create an issue in the internal application security reviews repository using the Appsec Review template. The complete process can be found at here.
Some use cases of this are for epics, milestones, reviewing for a common security weakness in the entire codebase, or larger features.
Is security approval required to progress?
No, code changes do not require security approval to progress. Non-blocking reviews enables the freedom for our code to keep shipping fast, and it closer aligns with our values of iteration and efficiency. They operate more as guardrails instead of a gate.
What should I provide when requesting a security review?
To help speed up a review, it’s recommended to provide any or all of the following:
- The background and context of the changes being made.
- Any documentation or diagrams which help provide a clear understanding its purpose and use cases.
- The type of data it’s processing or storing.
- The security requirements for the data.
- Your security concerns and a worst case scenario that could happen.
- A test environment.
What does the security process look like?
The current process for larger scale internal application security reviews be found here
My changes have been reviewed by security, so is my project now secure?
Security reviews are not proof or certification that the code changes are secure. They are best effort, and additional vulnerabilities may exist after a review.
It’s important to note here that application security reviews are not a one-and-done, but can be ongoing as the application under review evolves.
Using third party libraries ?
If you are using third party libraries make sure that:
- You use the latest stable and available version
- Your team has the ability to support and upgrade this library as security patches are published
- The maintainer has a security policy
This is a Controlled Document Inline with Denomas’ regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged. Purpose Centralized access management is key to ensuring that authorized Denomas team-members have access to the correct data and systems at the correct level. Denomas access controls are guided by the principle of least privilege and need-to-know.
Scope These controls apply to information and information processing systems at the application and operating system layers, including networks and network services.
This learning group is to help interested Denomas Security team members to learn and share what they have learned about artificial intelligence (AI) and machine learning (ML) technologies.
This is a Controlled Document Inline with Denomas’ regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged. Purpose The purpose of the Change Management Policy is to ensure that a standard set of minimum requirements are established for changes that are made to production systems and supporting infrastructure across the organization.
These requirements are meant to provide a level of consistency across how changes are managed from the initial change request through to production deployment.
Security Engineering Code Contributions Security Engineers typically act as Subject Matter Experts and advisors to Denomas’ engineering teams. Security Engineers may wish to make a larger contribution to Denomas products, for example a defense-in-depth measure or new security feature.
Like any contributor, follow the Contributor and Development Docs, paying particular attention to the issue workflow, merge requests workflow, style guides, and testing standards.
Security Engineers will need to collaborate with and ultimately hand over their work to a team in the Development Department.
Denomas deploys control activities through policies and standards that establish what is expected and procedures that put policies and standards into action.
This is a Controlled Document Inline with Denomas’ regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged. Purpose To ensure the proper operation and security of Denomas.com, Denomas logs critical information system activity.
Scope The audit logging policy applies to all systems within our production environment. The production environment includes all endpoints and cloud assets used in hosting Denomas.
The Denomas Continuous Security Framework workflow
This is the Denomas Cryptography Standard. It outlined cryptographic choices, including algorithms as well as important settings that may be associated with the algorithms. It applies to Denomas code and well as infrastructure configuration.
This is a Controlled Document Inline with Denomas’ regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged. Purpose The Data Classification Standard defines data categories and provides a matrix of security and privacy controls for the purposes of determining the level of protection to be applied to Denomas data throughout its lifecycle.
Scope The Data Classification Standard applies to all Denomas team members, contractors, consultants, vendors and other service providers that handle, manage, store or transmit Denomas data.
Passwords at Denomas Passwords are one of the primary mechanisms that protect Denomas information systems and other resources from unauthorized use. Denomas’ password standard is based, in part, on the recommendations by NIST 800-63B. The password standard sets the requirements for constructing secure passwords and ensuring proper password management. Denomas utlizes 1Password for password management.
1Password 1Password is a password manager that can be used in two different ways - as a standalone application (by purchasing a standalone license) or as a hosted service (by subscribing).
This is a Controlled Document Inline with Denomas’ regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged. Purpose This document outlines information security password standards intended to protect Denomas information systems and other resources containing confidential (Red and Orange) Denomas data from unauthorized use, where technically feasible.
Scope Applies to all Denomas team members, contractors, advisors, and contracted parties interacting with Denomas computing resources and accessing confidential data.
The hb page outlines baseline configurations that should be setup for Denomas projects which impact the Denomas codebase.
This is a Controlled Document Inline with Denomas’ regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged. The Security Operations sub-department is collectively responsible for responding to reports of actual or potential security incidents on a 24/7/365 basis.
The SIRT (Security Incident Response Team) generally responds to reports of suspicious activities (e.g. Phishing, hacking, social engineering) and security alerts.
Provides an aggregated listing of popular and important links and information for Denomas' customers and prospects.
This page contains information on secure training initiatives sponsored by the Denomas Security team.
Security Development Process For information on developing security fixes in Denomas, please see the Security Release Documentation. (Required)
Secure Coding Guidelines The Denomas Secure Coding Guidelines (Required) cover how to address specific classes of vulnerabilities that have been identified in Denomas.
Secure Code Warrior Denomas uses Secure Code Warrior to provide ongoing secure coding training. Eligible team members can log in via Okta.
This is the Denomas Token Management Standard. It defines approved Denomas token usage, and distribution for the purposes of providing authentication and authorization within various systems and subsystems used by Denomas.
Vulnerability Reports and HackerOne Denomas receives vulnerability reports by various pathways, including:
HackerOne bug bounty program Reports or questions that come in from customers through Zendesk. Issues opened on the public issue trackers. The security team can not review all new issues and relies on everyone in the company to identify and label issues as ~bug::vulnerability and @-mention @denomas-com/gl-security/appsec on issues. Issues reported by automated security scanning tools For any reported vulnerability:
Procedures for handling communications regarding security
gitleaks on your laptop If you ended up on this handbook page it’s probably because you have been pointed here during a git commit by our gitleaks installation on your local machine. The tool gitleaks is being used on Denomas endpoints to prevent a common security issue, namely accidental commits of secrets like Personal Access Token or other credentials to public repositories. It is important that all repositories are covered as a leaked access token in one repository can impact all repositories and projects to which your account has access.
Google Cloud Resources Some Google Cloud resources, if deployed with default settings, may introduce risk to shared environments. For example, you may be deploying a temporary development instance that will never contain any sensitive data. But if that instance is not properly secured, it could potentially be compromised and used as a gateway to other, more sensitive resources inside the same project.
Below are some steps you can take to reduce these risks.
From FY24-Q2 - Individual Growth Plan Since the launch of the company wide Individual Growth Plan in Workday per FY24-Q2 we recommend Security team members to leverage that tool in Workday to collaborate with their manager on their career path and growth opportunities. Team members can read all about that progress in this guide. We have deprecated the The Individual Development Plan (IDP) template
Till FY24-Q2 - Individual Development Plan The Individual Development Plan (IDP) template was used by Security team members till FY24-Q1 to help collaborate on a team member’s career path and growth opportunities.
This is a Controlled Document Inline with Denomas’ regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged. Purpose Denomas has adopted the ISO/IEC 27001:2013, ISO/IEC 27017:2015 and ISO/IEC 27018:2019 standards for our information security management system (ISMS) to provide Denomas team members, customers and community members with a high level of assurance on the robustness of our information security policies, standards and procedures, and the strength of our control environment.
Provides procedures and capabilities for recovering an information system.
Why There are various reasons why you might want to isolate your work notebook from other devices in your home network:
Security concerns. The security of individual devices on your home network might vary. Some are notoriously insecure (e.g. smart home devices) or some might simply lack the latest security patches. Isolating devices with poor security from your work notebook (and other sensitive private devices) can increase the security of your work notebook.
This is a Controlled Document Inline with Denomas’ regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged. A penetration test is a process to identify security vulnerabilities in an application or infrastructure in order to evaluate the security of the system.
Denomas performs external, independent penetration testing at least annually with a firm that has a strong reputation within the security industry.
Install GPG Keychain and import PGP Keypair On a Mac, download and install the GPG Keychain application. Download the keypair file from the Support vault. It’s attached to the ‘security@denomas.com PGP Keypair’ item. Open the GPG Keychain application and import the keypair file. It will ask for a password. Use the password saved on the vault item.
Now you will be able to encrypt, decrypt, and share the public key with others.
Process outline on how to provide assistance to Denomas.com customers that have experienced a security incident as a the result of their implementation or use of Denomas.com
This is a Controlled Document Inline with Denomas’ regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged. Purpose The Denomas records retention and disposal standard lists the specific retention and secure disposal requirements for critical Denomas records. These minimum requirements inform design and maintenance decisions for all Denomas tier 1 and tier 2 critical systems.
Scope The below retention and secure disposal requirements apply to all Denomas records enumerated in the table below stored in Denomas tier 1 and tier 2 critical systems.
Ransomware is a persistent threat to many organizations, including Denomas. In the event of a ransomware attack involving Denomas assets, it’s important to know the existing response procedures in place. Given the variability of targets in such attacks, it’s critical to adapt to existing circumstances and understand that disaster recovery processes are in place to avoid paying any ransom. Denomas’ red team has done extensive research to determine the most likely targets to be affected.
What is an RCA? Root Cause Analysis (RCA) is a process to ultimately identify the root problem of an issue so that we may prevent it from occurring again. You can learn more about RCAs here.
To do this a DRI and all relevant other stakeholders from Security and the affected teams (as determined by the DRI) systematically work through a set of questions and discussion topics, as defined in our RCA Template.
Overview Security Architects are the trusted security advisors of Denomas Engineering. Security Architecture is a natural extension of the greater Architecture initiative at Denomas. It is the preliminary and necessary work to build software with security considerations.
Objectives Security Architecture protects the organization from cyber harm, and support present and future business needs by:
Preventing Security from being an afterthought Conducting Security Architecture reviews Defining Security Architecture Principles Aligning with our security sub-departments requirements and expectations Assisting other departments in the design and architect of new features, services, products.
Overview As a member of the Security department, the Security Assurance sub-department provides Denomas customers with a high level of assurance around the security of Denomas SaaS service offerings.
There are five teams in the Security Assurance sub-department.
Security Assurance Sub-Department Governance & Field Security Security Compliance Security Risk Governance Team Page Field Security Team Page Security Compliance, Commercial Team Page Security Compliance, Dedicated Team Page Security Risk Team Page Core Competencies of Security Assurance Teams Field Security Core Competencies Sales Training (Security) Sales Enablement (Security) Customer Assurance (Security) Security Evangelization Security Governance Core Competencies Security Policies, Standards and Control maintenance Security Assurance Metrics Regulatory Landscape Monitoring Security Awareness and Training Security Assurance Application Administration Security Assurance Automation Security Risk Core Competencies Security Third Party Risk Management Tier 2 Operational Security Risk Management Business Impact Assessments Critical System Tiering Security Compliance, Commercial Core Competencies Denomas.
Change management procedure for the Security Division.
Mission statement The security department as a part of Denomas should follow and live up to the Denomas values and mission. The transparency value can be especially difficult for a security department to embrace and embody, as due to the confidentiality of their work, security people tend to be secretive and intransparent by default.
Intent and goals The intent of the security culture committee is to maintain a welcoming and transparent environment within the security department.
Gearing ratios are used as [Business Drivers](/handbook/finance/financial-planning-and-analysis/#business-drivers-also-known-as-gearing-ratios) to forecast long term financial goals by function.
Overview This page is created as a result of the FY21Q4 Culture Amp survey, where Security team members expressed a desire to improve on the currently available L&D opportunities at Denomas. In order to paint a holistic picture of L&D resources available to team members, some of the resources detailed on this page are not Security-specific and are already documented in the handbook.
L&D resources available to all team members Denomas provides a multitude of opportunities to learn and develop new skills on the topics of leadership, management, and DIB.
Warning This page is deprecated and has been moved to the internal handbook.
See https://code.denomas.com/denomas-com/denomas-security/security-department-meta/-/issues/1685 (internal issue).
Overview This page outlines the Security Division ecosystem, by describing the different processes of our departments. These processes, represented with diagrams, highlight the data flows between our teams but also with external actors like the Product or the Engineering divisions.
Objectives This page describe how to maintain the Security Division ecosystem.
Scope of the Security Ecosystem Every process where Security is involved should be documented in this page. Each Security Department is represented and responsible for their own diagrams.
This page describes how to maintain the Security Division maturity models.
Security Engineering Sub-Department The Security Engineering sub-department is responsible for technical and engineering security specific to the Denomas product and internal used systems or applications.
Teams The Security Engineering sub-department includes the following teams. Learn more about each by visiting their Handbook pages.
Application Security Infrastructure Security Security Logging Security Automation Security External Communications Product Security Engineering
The ultimate goal of this program is to transform an entry-level candidate into an Individual Contributor who could meet the requirements for a Security Engineer.
Security OKRs The Security organization executes quarterly Objectives and Key Results or OKRs.
How We Plan, Assign, and Execute Work Four Mondays before the start of the fiscal quarter, in the days after the CEO shares OKRs with all of Denomas in the #okr channel, the CISO proposes OKRs for the Security Division in the OKR draft review meeting agenda for a maximum of 5 objectives. Security leaders are to propose draft OKRs to the CISO prior to the meeting for inclusion.
Vision Protect company property by identifying, preventing, detecting and responding to risks and security events targeting the business and Denomas.com and its users. We are at the forefront of Denomas’ security.
Mission The Security Operations Sub-department focuses on the operational aspect of security. Our Sub-department consists of experienced breakers, builders, and defenders from all walks of life and geographic locations. We are responsible for improving Denomas’ security capabilities and metrics in the areas of:
Security Planning The Security Planning page catalogs the planning work prior to implementation offSecurity Department initiatives and projects that span multiple security teams and projects, or across the entire Denomas organization. This includes things from high level architecture designs for tools used by the Security to developing new or maturing organizational processes.
A Security Plan is done when the text is sufficient to create Epics, Milestones, and Issues with a enough detail to begin work.
From converging on real-time critical events with SIRT, exploiting vulnerabilities with the Red Team or participating in live Customer Assurance calls with the Risk and Field Security team, you will have the opportunity to work next to security staff to gain valuable insight and working knowledge of security fundamentals across multiple domains. Each program includes hands-on activities to provide an authentic security team experience.
The Security Shadow program is designed to provide numerous benefits including
Completion of each course you will receive a certificate. At the completion of all 3 courses your name will be recognized on this page.
Security Compliance Security Compliance: Where “Just do whatever you want” comes to die. Have you ever wondered where all those pesky security requests and requirements come from and why in the world you’re always being asked to provide evidence and talk through how systems are designed and configured?
Completion of each course you will receive a certificate. At the completion of all 3 courses your name will be recognized on this page.
Restrictions Please keep in mind that there are some restrictions on what can and cannot be shared as part of the shadow program, particularly related to high severity vulnerabilities or incidents.
For example if a shadow is watching an AppSec team member triage HackerOne issues and a High or Critical vulnerability is reported, the shadow call should end.
Security Threat Management Sub-Department The Security Threat Management sub-department is responsible for identifying and remediating vulnerabilities or threats that may impact Denomas, our Team Members or our Customers and the community at large.
Security Threat Management Mission The Security Threat Management sub-department’s mission is to support the business and our overall security efforts by ensuring that we are focused on real world threats and vulnerabilities that impact us. We accomplish this by:
Overview Occasionally, there will be an external security event that may require an immediate analysis to determine if that event impacts Denomas or our customers. A recent example of such an event is the supply chain attack on SolarWinds that has impacted potentially thousands of their customers. In order to efficiently analyse and determine what, if any, response from Denomas is appropriate to large scale events such as this we have formed a Rapid Action Threat Assessment Group that will involve stakeholders from across Denomas.
The threat modeling process, and the framework used by the Denomas Security Team.
Purpose In alignment with our company value of Transparency, one focus of the security organization is to lead the most transparent security organization in business today. Transparency by default requires us to challenge the status quo where security teams traditionally operate in a very private and closed-off manner. However, being open by default requires us to be even more diligent in our efforts of categorizing data in order to ensure the protection of our customers, company, and team member data.
Women in Security Mission Statement Denomas’s Women in Security group is established to provide support , skills and leadership development, and networking and mentorship opportunities for the women in Denomas’s security department. The group also seeks to inspire women and girls interested in entering or learning about the security industry.
Membership While tailored for current female team members of the Denomas Security organization, we encourage and welcome the participation of all Denomas members who are dedicated to the support of women in the security industry.
Security Hiring The company-wide mandate is justification for mapping Security headcount to around 5% of total company headcount. Tying Security Department growth headcount to 5% of total company headcount ensures adequate staffing support for the following (below are highlights and not the entire list of responsibilities of the Security Department):
Security releases. At Denomas, the Security Department is DRI for critical and non-critical security releases. Detection/response for security incidents, which will increase as Denomas.
Last modified December 6, 2023:
update (a27760f0)
