diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Azure DevOps Comparative Assessment.md b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Azure DevOps Comparative Assessment.md new file mode 100644 index 000000000..4ea2d72f4 --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Azure DevOps Comparative Assessment.md @@ -0,0 +1,211 @@ +--- +sidebar_position: 9 +--- + +# Comparative Analysis of Jira vs. Azure DevOps +By Candice Smith + +:::info +**Document Creation:** December 8, 2024. **Last Edited:** December 8, 2024. **Authors:** Candice Smith. +**Document Code:** ADO-COMP-001. **Effective Date:** December 8, 2024. **Expiry Date:** December 8, 2025. +::: + +## Executive Summary + +Redback Operations have been utilising GitHub and Microsoft Planner to project manage the work being conducted by their Capstone cohorts each trimester. There are many challenges that go along with this approach; lack of interoperability between the two platforms, lack of functionality and scalability for Microsoft Planner, and GitHub is not the best tool to use for document repository purposes. + +In this document we are presenting a comparison of the two systems and making our recommendation on the most suitable path forward, which is implementation of the Azure DevOps Platform. We also provide steps to migration from the current platforms. + +## Requirements + +### Current Challenges +* Major security issues around content housed within GitHub and Thingspeak as it is publicly accessible, major risk around API keys, credentials and personal and health information being shared publicly. +* Disparate environments, Planner does not integrate with developer pipeline so the two are operating in a mutually exclusive way, and there are also other tools being used outside these two main platforms such as Thingspeak, and teams using planner to hold important team information. +* Planner does not allow for sprint management across Redback Teams. +* Planner requires a full manual reset and update every trimester and does not handle carry over tasks well. +* Use of GitHub for documentation including pull request process has proven challenging and time-consuming meaning students are spending more time on upload and less time on contributions. +* Limited reporting in Planner makes end of unit submissions too manual. +* Planner has limited customisation. +* Inefficiencies switching between both platforms to update progress. + +### Goals +* Integrate and unify development pipelines with project management for increased efficiency. +* Improve the ability to report on contributions for all students through auditing and reporting. +* Access a more feature rich environment to being to implement new features and tools and elevate student contributions to Redback Operations. +* Provide a secure and compliant research environment for future Redback Operations cohorts, protected by our Deakin network and credentials. + +## Comparison Overview + +| Feature | Jira | Azure DevOps | +| --- | --- | --- | +| Task & Project Management | Good for agile frameworks (Scrum, Kanban). Provides robust tools for issue tracking, workflows, and reporting. | Integrated Boards with agile tools, customisable workflows, and strong integration with CI/CD pipelines. | +| Code Repository | Will rely on integration with external GitHub repositories. Native repo functionality available only in Bitbucket. | Offers Azure Repos as a built-in Git-based repository or integrates seamlessly with GitHub. | +| Pull Requests | Pull requests managed through GitHub. Tracks them as linked issues. | Native pull request management within Azure Repos or integrates with GitHub. | +| Document Repository | No native document repo; relies on Confluence or external tools like Google Drive or SharePoint. | Supports document storage as part of Azure Repos or integrated storage in projects. | +| Integrations | Strong ecosystem with Atlassian tools (Confluence, Bitbucket) and third-party apps. | Tight integration with other Microsoft tools (e.g., Teams, SharePoint, Power BI) and GitHub. | +| Reporting and Analytics | Excellent reporting with dashboards and 3rd-party apps. Advanced plugins available. | Built-in advanced reporting and analytics tied to pipelines, test plans, and projects. | +| Ease of Use | Straightforward for agile teams but may require customisation for other workflows. | Familiar for organisations already using Microsoft tools; offers streamlined workflows. | +| Scalability | Scales well for project management but depends on integrations for code and CI/CD. | End-to-end solution for project management, repositories, and CI/CD in one platform. Scales well. | +| Cost | Standard licensing is $7.53 per user per month. For 100 Students in a 12-week trimester that totals $2,259. | Most students added as Stakeholders which is free. Only Leaders require basic licencing. There are some add-ons to watch out for, but this would be below $1,000. | +| Other | Jira is a widely used platform, offering interaction with an industry standard. | Azure offers a complete end-to-end solution that in tightly integrated with existing Teams and SharePoint tools. | + +## Detailed Comparison +### Task and Project Management +#### _Current State_ +The Redback Ops teams currently use Microsoft Planner for task management. Microsoft Planner offers a straightforward, one-dimensional Kanban-style interface. It allows users to move tasks across swim lanes, assign task owners, manage short and simple checklists within tasks, set due dates, and apply tags, among other basic functionalities. + +#### _Jira Option_ +Jira offers a scalable, highly customisable project management platform with advanced Kanban and Scrum capabilities. It is superior to Planner as it offers the opportunity to define custom workflows, issue types, and field configurations, as well as supporting Agile methodologies natively with tools for sprints, backlogs, and epics. Users can create detailed workflows, track issues, prioritise backlogs, and integrate with an extensive range of tools such as GitHub, Slack, and Confluence. Its reporting features provide actionable insights into team performance with burn-down charts, velocity tracking, and issue-resolution metrics. With all this functionality Jira can demand a steep learning curve, and could even be overwhelming for smaller, less complex projects. Jira is also typically more expensive on licensing costs. + +#### _Azure DevOps Option_ +Redback Ops teams could also consider transition to Azure Boards, part of the Azure DevOps ecosystem. Boards provides built-in Kanban and Scrum boards, which integrate seamlessly with Azure Repos, Pipelines, and other DevOps tools, offering end-to-end project visibility and development lifecycle management. Boards offer customisable workflows, work items, and backlog management with strong support for Agile and Scrum methodologies. It is typically more cost-effective than Jira and easier to migrate to for teams already in the Microsoft ecosystem. Jira does have more integration opportunity, however with integration comes the requirement for configuration which can mean complex process and additional work. While there is reporting functionality Jira does tend to have more templated reporting available. + +_Recommendation:_ Both Jira and Azure offer their own benefits and would deliver a robust and effective solution in this space, no clear preference can be made for this criterion. + +### Code Repositories +#### _Current State_ +Redback Operations currently utilise GitHub repositories for development work, benefiting from extensive functionality and tooling. However, the repositories used for Redback Operations' development pipelines are currently public, which poses significant risks. The most critical include the potential for leaked credentials or API keys if inadvertently committed by developers and missed in the code review process, and the accidental exposure of sensitive or private information, such as protected health information. These incidents could result in violation of privacy regulations, including the _Privacy Act 1988_, and lead to serious consequences for Deakin University. + +#### _Jira_ +Jira does not provide native code repository functionality but integrates with the Atlassian code repository management platform, Bitbucket. It can also integrate with other third-party solutions like GitHub or GitLab. Bitbucket offers private repositories with access control, branch permissions, and in-depth Jira integration for tracking and traceability of issues and linking them to commits, branches, and pull requests. This integration can streamline development workflows by creating a unified environment for task management and code management. Moving to Jira would require either migrating to Bitbucket or continuing to use GitHub, which could complicate the setup. Additionally, Atlassian’s pricing model might increase costs for teams scaling repository usage. Managing multiple tools can add additional complexity despite the integration opportunity between the two. + +#### _Azure DevOps_ +Azure DevOps offers Azure Repos, a fully integrated code repository solution with good security, branch policies, and pull request workflows. It offers both Git-based repositories and Team Foundation Version Control (TFVC) to accommodate diverse development needs. Azure Repos is deeply integrated with other Azure DevOps services, enabling seamless traceability between code changes, work items, and builds. This makes it appealing for organisations already using Azure Boards or Pipelines due to the native integration within the one platform. Azure DevOps provides enterprise-grade security features, such as built-in support for branch protection rules, advanced auditing, and private repositories by default, reducing the risk of accidental data exposure. Azure DevOps does provide less integration opportunity – but that is not an issue when it offers all the tooling we require natively within that platform. Transitioning from GitHub may require migrating repositories and adjusting workflows which would be a decent sized piece of work, but there are some built in tools that can assist. + +_Recommendation:_ Azure Repos is a good option under this criterion. The team currently operates within the Microsoft ecosystem and would benefit from a fully integrated DevOps solution within the same. Azure Repos offers a native, secure, and streamlined option for repository management, minimising the need for external integrations. + +### Pull Requests (PRs) +#### _Current State_ +Redback Operations currently uses PRs within GitHub. This approach offers the ability to review, discuss, approve PRs using workflows, perform code reviews, inline commenting, and status checks. These actions all work together to help enforce quality and prevent unintentional defects in the codebase. Unfortunately, the team can also, occasionally, face challenges around enforcing a consistent review process and integration with project management workflows, particularly regarding the limitations around associating pull requests with tasks in Microsoft Planner. The lack of deep integration with current task tracking tools limits traceability and the ability to streamline development pipelines. + +#### _Jira_ +Jira offers indirect integration with PR workflows through Bitbucket, GitHub, or GitLab. When being utilised with Bitbucket, Jira enables comprehensive linking between issues and PRs, offering traceability from development to deployment. Developers can view PR details within Jira, enhancing visibility across all team members. Jira can automate transitions between issue statuses based on PR activity, improving workflow efficiency. This functionality does depend heavily on proper setup and the choice of an external repository platform. Using a combination of Jira and GitHub for PRs may fragment the development pipeline, creating additional complexity for maintaining integrations and workflows. While this approach offers flexibility, it also requires extensive configuration and regular updates to keep processes aligned. + +#### _Azure DevOps_ +Azure DevOps natively supports pull requests using Azure Repos, offering a streamlined, secure, and integrated experience. PRs in Azure DevOps include built-in policies, such as mandatory reviews, work item linking, and customisable status checks, ensuring high code quality and compliance. The platform allows automated pipelines to trigger builds and tests on PR creation, providing immediate feedback to developers. Integration with Azure Boards ensures complete traceability, enabling users to link PRs with specific tasks, bugs, or features. For teams operating within the Microsoft ecosystem, the native integration reduces complexity and simplifies workflows. Azure DevOps provides advanced auditing capabilities, which are especially critical for regulated environments like Redback Operations, and to support assessment driven by the teaching team across Capstone. Transitioning to Azure DevOps may require adjustments to existing workflows, but the native tools and integrations significantly reduce setup and maintenance overhead. + +_Recommendation:_ Azure DevOps offers a more effective solution for managing pull requests due to its deep integration with other tools within the platform, namely, Azure Boards and Pipelines. Its built-in security and compliance features make it an ideal choice for Redback Operations. While Jira and Bitbucket provide a strong combination for teams using Atlassian tools, the lack of native support for pull requests within Jira itself introduces additional complexity. The unified nature of the Azure DevOps’ ecosystem makes it a more efficient and secure choice for managing PRs in alignment with Redback’s development workflows. + +### Document Repositories +#### _Current State_ +Redback Operations uses GitHub repositories for storing and managing documents. While GitHub provides version control and collaboration features, it is not the best choice for structured document management or workflows. Lack of features such as custom metadata, advanced search, and integrated approval workflows can limit its usability for large-scale or compliance-critical documentation. Additionally, versioning for non-code documents (e.g., policies or designs) can feel clunky in a Git-based system. + +#### _Jira_ +Jira does not natively offer document repository functionality; however, Atlassian’s Confluence integrates well with Jira to provide strong document management capabilities. Confluence supports structured pages, hierarchical organisation, metadata, and collaborative editing, making it a powerful tool for documentation. Linking documents stored in Confluence to Jira issues improves traceability between project tasks and supporting documentation. This combination enables teams to centralise documentation and manage it alongside task tracking. The challenge with this option is the reliance on a separate tool (Confluence) which adds cost and requires additional setup and maintenance. Teams would need to migrate existing documents to Confluence and adapt new workflows for the new system. + +#### _Azure DevOps_ +Azure DevOps includes Wikis for lightweight documentation and markdown-based collaboration, allowing teams to create and manage project documentation directly within the platform. For more structured or enterprise-grade document management, Azure DevOps can integrate with Microsoft SharePoint, leveraging its extensive features such as metadata tagging, advanced search, version control, and approval workflows. SharePoint provides a centralised repository for storing and managing large volumes of documents, ensuring compliance with organisational policies and regulations. This integration allows teams to link SharePoint documents to Azure Boards work items, pull requests, or pipelines, enhancing traceability. SharePoint also integrates well with other Microsoft tools like Teams and Outlook, creating a complete collaboration ecosystem. Combining Azure DevOps Wikis for quick documentation and SharePoint for comprehensive document management offers flexibility and scalability, tailored to the team’s needs. + +_Recommendation:_ Azure DevOps provides a versatile approach to documentation by combining its native Wiki functionality with the powerful capabilities of SharePoint. This dual-option setup aligns well with Redback Operations’ Microsoft ecosystem and offers a secure, integrated solution for managing documentation. For teams with structured document requirements, leveraging SharePoint alongside Azure DevOps ensures comprehensive and compliant document management while minimising the need for third-party tools. + +### Integrations +#### _Current State_ +Redback Operations uses Microsoft Planner for task management and GitHub for code repositories and associated processes. Outside of this they typically work in Microsoft Teams as their digital workspace. Tighter integration between tools would be very beneficial to enhance collaboration and efficiency. Currently other than embedding the planner boards within Teams, the connections are very limited at best, leading to manual work and double handling in certain processes. + +#### _Jira_ +Jira supports a wide range of integrations with Atlassian tools (Bitbucket, Confluence, Trello) and third-party platforms (like Slack, GitHub, and Microsoft Teams). It offers APIs, webhooks, and Atlassian Marketplace apps to extend functionality and customised integrations to fit existing workflows. Managing multiple integrations can increase administrative complexity though, and the quality of third-party integrations can vary. Ensuring they remain up to date with changing requirements and software updates is essential and can mean additional work. + +#### _Azure DevOps_ +Azure DevOps provides built-in integrations with other Microsoft tools like Teams, Outlook, and Power BI, creating a streamlined ecosystem for teams working within the Microsoft stack. It also supports external integrations through its REST APIs and service hooks, integrating with platforms like GitHub, Jira, and various CI/CD tools. The native integrations with Azure Boards, Pipelines, and Repos reduce the reliance on external tools, simplifying workflows and improving productivity. + +_Recommendation:_ While Jira may offer more integration flexibility and supports a broader ecosystem, Azure DevOps can offer a completely unified experience within the Microsoft ecosystem. For Redback Operations, where Microsoft tools are already in use, Azure DevOps offers the most seamless integration, making it the preferred choice for this criterion. + +### Reporting and Analytics +#### _Current State_ +Redback Operations relies largely on manual process to report on work that has been completed throughout the trimester. Students complete manual updates and submit these for review. Tasks tracked in Microsoft Planner, while can be dumped into a csv file for analysis, remain attached to a heavily manual process and there is currently no dashboard or intuitive reporting tools that can help convert the work done into a useful and effective summarised output. There is not currently an easy way to generate insights and track performance metrics across projects. With this this approach which limits the ability to create tailored reports or dashboards, it can lead to delays in decision-making meaning less progress per trimester, and reduced visibility into project performance. + +#### _Jira_ +Jira offers advanced reporting and analytics with built-in dashboards, custom filters, and gadgets. Teams can track project progress, burndown charts, sprint performance, and issue resolution times. Jira offers integration with Atlassian Analytics and other tools like Confluence to enhance reporting capabilities further, allowing teams to consolidate data from multiple sources into useful insights that can greatly support continuous improvement. The major limitation is that these advanced analytics often require additional tools or licensing, increasing costs and complexity. + +#### _Azure DevOps_ +Azure DevOps provides comprehensive reporting and analytics capabilities through built-in dashboards, query-based reports, and integration with Power BI. These features allow teams to track work item progress, pipeline performance, and code quality metrics across projects. Power BI integration offers advanced data visualisation, enabling teams to create custom dashboards that consolidate data from Azure DevOps and other sources into easy to consume diagrams and tables. The native reporting tools are easy to use and require minimal setup, they also emphasise traceability, ensuring all data is tied back to work items or code changes. + +_Recommendation:_ Azure DevOps is the preferred choice for reporting and analytics due to its native integration with Power BI, a Microsoft tool aligning with Redback Operations’ existing Microsoft ecosystem. Its advanced data visualisation capabilities, and traceability features, make it the preferred tool for creating tailored dashboards that consolidate project data and metrics. Azure DevOps emphasises auditability, providing detailed tracking of user activities across work items, pull requests, and pipelines. This transparency could enable the teaching team to monitor who has completed specific tasks, contributed code, or updated documentation, fostering accountability and simplifying assessment for the unit. While Jira offers strong analytics capabilities, the reliance on additional tools for advanced reporting adds complexity. Azure DevOps delivers a more streamlined, integrated, and auditable solution for tracking and visualising student and project performance. + +### Ease of Use +#### _Current State_ +Redback Operations currently uses Microsoft Planner for task management and GitHub for repositories, which provides a reasonably simple and familiar interface for users. However, the simplicity of particularly Microsoft Planner comes at the cost of limited functionality, lacking the ability to handle complex workflows, advanced project management, and integrations. The current GitHub processes can be a little more challenging particularly around the use of the Docusaurus tool with Markdown conversion and the pull request process both playing a role in the challenging nature of posting completed works and research in the centralised repository. + +#### _Jira_ +Jira is a feature-rich platform with advanced capabilities for project management and Agile workflows, such as Scrum and Kanban boards, issue hierarchies, and custom workflows. Its complexity can be overwhelming for new users, requiring training and onboarding to fully utilise its capabilities, this could be a major issue with the limited time available in each trimester to make significant technical contributions. The interface has improved with recent updates, but it remains far less intuitive than simpler tools like Microsoft Planner. Jira's flexibility is a strength, particularly with experienced technical teams, but for less experienced users like many students, the learning curve can hinder adoption. + +#### _Azure DevOps_ +Azure DevOps is designed to integrate seamlessly with the Microsoft ecosystem, providing a familiar interface for teams already using Microsoft tools. Features like Azure Boards, Repos, and Pipelines are intuitive for users familiar with tools like Planner and GitHub, making for a much easier transition. The platform's design balances usability and advanced functionality, ensuring accessibility for both technical and non-technical users. Integrated wikis, dashboards, and reporting tools are easy to navigate, leading to improved team collaboration. + +_Recommendation:_ Azure DevOps offers a gentler learning curve for Redback Operations due to its alignment with existing tools and workflows. While Jira is more feature-rich, Azure DevOps prioritises usability and accessibility, making it the preferred choice. + +### Scalability +#### _Current State_ +Microsoft Planner and GitHub are effective for small to medium-sized projects but lack the features needed to scale up and facilitate more complex, multi-team operations. Limited task hierarchy, workflow automation, and reporting capabilities hinder scalability, and the lack of integration between the two means there is a lack of efficiency hindering growth. + +#### _Jira_ +Jira excels in scalability, supporting complex, large-scale operations with customisable workflows, issue hierarchies, and advanced reporting. It’s highly configurable and can handle extensive Agile projects, making it suitable for organisations with diverse teams and processes. Scaling Jira requires very careful management of configurations and integrations, which often means increased complexity. + +#### _Azure DevOps_ +Azure DevOps is also highly scalable, designed for enterprises managing complex development pipelines, multiple teams, and integrated workflows. It has a modular architecture which supports scaling specific components, like Azure Boards for task management or Azure Pipelines for CI/CD processes. Integration with Azure ensures scalability in cloud-based environments, while SharePoint offers a scalable solution for document management. Azure DevOps aligns well with Redback Operations’ growing needs, supporting advanced reporting, cross-team collaboration, and automation. + +_Recommendation:_ Both Jira and Azure DevOps are highly scalable, but Azure DevOps offers a smoother growth path for Redback Operations by leveraging its integration with the Microsoft ecosystem. Its modular approach and flexibility make it the more practical choice for scaling operations efficiently. + +### Cost +#### _Current State_ +Redback Operations primarily uses Microsoft 365 and GitHub, which are cost-efficient for basic task and code management. However, scaling these tools for more complex project management, compliance, or structured documentation requires third-party tools, increasing costs. + +#### _Jira_ +Jira operates on a subscription model, with pricing based on the number of users. Costs can escalate when paired with required tools like Confluence or Bitbucket for documentation and code management. While the Atlassian suite provides comprehensive functionality, organisations must budget for these additional tools, making it less cost-effective for teams already invested in other ecosystems. + +I have made the following estimation on pricing for this solution for 100 Students x 3 months: + +Jira – Standard $7.53 per user per month = $2,259 +Bitbucket – Standard $3.30 per user per month = $990 +Confluence – Standard $5.16 per user per month = $1,548 + +**Jira Forecast Total - $4,797 per trimester** + +#### _Azure DevOps_ +Azure DevOps is available as part of Microsoft’s suite of tools, often included in existing Microsoft 365 or Azure subscriptions, which can reduce costs for organisations such as Redback, already in the Microsoft ecosystem. Integration with SharePoint and Teams, typically included in enterprise licenses, further minimises additional expenses. The cost model is user-based but scales favourably compared to Jira when leveraging existing licenses. + +Given there is currently M365 licensing in place for Deakin Students the following assumptions can be made: + +Most users can be added as stakeholders as an inclusion in their existing M365 licensing. +Only Leaders require basic licensing which is likely to stay under paid licences per trimester. +For this assessment, we are assuming there are 20 basic licences required each trimester at $9.28 per user per month. + +**Azure DevOps Forecast Total - $556.80 per trimester** + +_Recommendation:_ As demonstrated in the above figures, Azure DevOps provides a more cost-effective solution, leveraging existing Microsoft investments. While Jira is competitive for standalone implementations, the added cost of supplementary tools makes Azure DevOps the preferred option. + +### Other Considerations +#### _Current State_ +Redback Operations currently uses a combination of Microsoft Planner, GitHub, and Teams, creating a fragmented ecosystem. While these tools fulfill basic needs, they lack seamless integration, leading to inefficiencies and manual effort. Transitioning to a unified platform can address these challenges by enhancing collaboration and improving workflow automation. + +#### _Jira_ +Jira is a widely used platform recognised as an industry standard for Agile project management. The extensive Atlassian ecosystem, marketplace, and support for third-party integrations make it a strong option for teams across industries. Implementing Jira can improve collaboration with external teams and vendors already familiar with the tool. The lack of native integration with core tools already in place, like Teams and SharePoint, would require additional customisation and implementation of further new tools like Confluence to close the gaps. + +#### _Azure DevOps_ +Azure DevOps provides a tightly integrated, end-to-end solution within the Microsoft ecosystem. Its seamless interaction with Teams and SharePoint enables streamlined communication, document management, and task tracking. This integration reduces the need for third-party tools, simplifying workflows and improving productivity. Azure DevOps' focus on delivering a cohesive experience aligns with Redback Operations’ existing tools, ensuring a smoother transition and reducing overhead. + +_Recommendation:_ While Jira offers the benefit of being an industry-standard platform, Azure DevOps provides a more integrated and complete solution for Redback Operations. Its alignment with existing Microsoft tools ensures a unified ecosystem, reducing complexity and enhancing efficiency. This will result in students being able to focus on their technical contributions to the products Redback Operations are developing in health and fitness rather than spending time on enterprise architecture, implementation of internal tools and systems, enablement for these platforms and onboarding each trimester. This makes Azure DevOps the stronger choice for teams already invested in the Microsoft environment as Redback Operations are. + +## Comparison of Migration + +| Aspect | Jira Migration | Azure DevOps Migration | +| --- | --- | --- | +| Task Migration | Straightforward CSV import with field mapping. | Straightforward CSV import with field mapping. | +| Code Integration | Retain GitHub; integration is simple. Alternatively, Bitbucket, part of the Atlassian Suite. | Option to retain GitHub or migrate to Azure Repos. | +| Documentation | Requires Confluence (additional tool). | Azure Wiki is built-in or use SharePoint. | +| Training | Focus on Jira and Confluence. | Focus on Azure Boards, Repos, and Pipelines. | +| Scalability | Highly scalable with Atlassian ecosystem. | Unified platform for scalability. | + +As far as migration from Microsoft Planner to each of the above alternative solutions goes, Azure DevOps once again offers the best overall option being more straightforward when it comes to enablement, provides unified platform including repos protected by credentials delivering the security that is currently lacking in GitHub. + +## Recommendation – Azure DevOps + +Following the above investigation, it is recommended that we move to the Azure DevOps platform rather than Jira for the following reasons: + +* While Jira excels in project management and agile workflows when paired with GitHub and Confluence, this would mean the introduction of a whole new product suite to achieve the same functionality as Azure DevOps which would be more costly and will still leave users moving between platforms. +* Azure DevOps provides a much more integrated, end-to-end experience for task management, code, and documentation and can integrate well with other tools being used like SharePoint and Teams. +* Azure DevOps is more cost effective. +* Azure DevOps gives us the flexibility to decide whether we want to continue using GitHub or move to the native repos and pipelines within the platform. +* Azure DevOps is strong in all areas, whereas there are limitations with the Atlassian product suite. +* Azure DevOps will be far easier for access control as mentors can control access easily through Deakin M365 IAM control. +* Opens the door to utilising Azure for cloud requirements over Google (GCP) providing further integration still throughout the company’s tooling. diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Azure DevOps Quick Start Guide.md b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Azure DevOps Quick Start Guide.md new file mode 100644 index 000000000..e18bddcc8 --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Azure DevOps Quick Start Guide.md @@ -0,0 +1,173 @@ +--- +sidebar_position: 10 +--- +# Azure DevOps Quick Start Guide + +:::info +**Document Creation:** December 15, 2024. **Last Edited:** December 15, 2024. **Authors:** Candice Smith. +**Document Code:** ADO-QUIK-001. **Effective Date:** December 15, 2024. **Expiry Date:** December 15, 2025. +::: + +Following an assessment of Jira and Azure we underwent configuration of Azure DevOps. We identified that there are two big risks we can ultimately mitigate with the migration: + +- Publishing of all Redback content to our public GitHub repos exposes us to inadvertently publishing sensitive information such as credentials, API Keys, and personal and health information +- Planner not being a comprehensive enough project management tool to handle the dynamic and evolving nature of a Capstone company. +This trimester we focused on creating a minimum viable product which would facilitate initial migration and allow future teams to make iterative improvements to the environment. We created a project space for all teams, sprints for T1 2025 and boards for project management, then migrated all content from Planner to Boards. Wikis and dashboards have been set up where possible and testing of these tools has been conducted. + +This guide will give you an overview of how to get started using Azure DevOps in place of Planner boards. + +## Current Configuration Progress by Team + +- Done CS - Candice Smith Completed +- Done Other - Completed by another team member +- OOS - Out of scope T3 2024 +### Project 1 + +- Done CS - Set up project +- Done CS - Allocated Ben Stephens as admin +- Done CS - Set up Areas – IoT, VR, Web +- Done CS - Added sprints for T1 2025 +- Done CS - Set Up Boards columns +- Done CS - Added “perpetual informational planner items” as Wikis +- Done CS - Added VR Team Work Details Handbook into Wiki +- Done CS - Added Welcome Wiki +- Done CS - Planner Migration (add planner tasks as user stories with checklist as tasks) +- Done CS - Embed Boards into Teams for T1 2025 instead of Planner. +- Not Started: GitHub Integration +- Not Started: Set up Dashboard +- Not Started: GitHub to Azure Repos migration +### Project 2 + +- Done CS - Set up project +- Done CS - Allocated Ben Stephens as admin +- Done CS - Added sprints for T1 2025 +- Done CS - Set Up Boards columns +- Done CS - Added Welcome Wiki +- Done CS - Added Closed Tasks +- Done CS - Planner Migration (add planner tasks as user stories with checklist as tasks) +- Done CS - Embed Boards into Teams for T1 2025 instead of Planner. +- Not Started: GitHub Integration +- Not Started: Set up Dashboard +- Not Started: GitHub to Azure Repos migration +### Project 3 + +- Done CS - Set up project +- Done CS - Allocated Ben Stephens as admin +- Done CS - Added sprints for T1 2025 +- Done CS - Set Up Boards columns +- Done CS - Added “perpetual informational planner items” as Wikis +- Done CS - Planner Migration (add planner tasks as user stories with checklist as tasks) +- Done CS - Embed Boards into Teams for T1 2025 instead of Planner. +- Not Started: GitHub Integration +- Not Started: Set up Dashboard +- Not Started: GitHub to Azure Repos migration +### Project 4 + +- Done CS - Set up project +- Done CS - Allocated Ben Stephens as admin +- Done CS - Added sprints for T1 2025 +- Done CS - Set Up Boards columns +- Done CS - Added “perpetual informational planner items” as Wikis +- Done CS - Planner Migration (add planner tasks as user stories with checklist as tasks) +- Done CS - Embed Boards into Teams for T1 2025 instead of Planner. +- Not Started: GitHub Integration +- Not Started: Set up Dashboard +- Not Started: GitHub to Azure Repos migration +### Project 5 + +- Done CS - Set up project +- Done CS - Allocated Ben Stephens as admin +- Done CS - Added sprints for T1 2025 +- Done CS - Set Up Boards columns +- Done CS - Added “perpetual informational planner items” as Wikis +- Done CS - Planner Migration (add planner tasks as user stories with checklist as tasks) +- Done CS - Embed Boards into Teams for T1 2025 instead of Planner. +- Not Started: GitHub Integration +- Not Started: Set up Dashboard +- Not Started: GitHub to Azure Repos migration +### Data Warehouse - Jesse + +- Done Other - Set up project +- Done Other - Allocated Ben Stephens as admin +- OOS - Added sprints for T1 2025 – Jesse would prefer no sprints so all items can be seen in a unified task view +- Done CS - Set Up Boards columns +- OOS - Planner Migration (complete - The DW team's planner board is from T2 and can be deleted/wiped. All the required information or tasks that carried over to this trimester have been moved to azure boards.) +- Done CS - Embed Boards into Teams for T1 2025 instead of Planner. +- Not Started: GitHub Integration +- Not Started: Set up Dashboard +- Not Started: GitHub to Azure Repos migration +### Cyber Security - Tristan + +- Done Other - Set up project - Done +- Done Other - Allocated Ben Stephens as admin - Done +- Done Other - Added sprints for T1 2025 - Done +- Done CS - Set Up Boards columns +- Codey to complete: Added “perpetual informational planner items” as Wikis +- Codey to complete: Planner Migration (add planner tasks as user stories with checklist as tasks) +- Codey to complete: Embed Boards into Teams for T1 2025 instead of Planner. +- Not Started: GitHub Integration +- Not Started: Set up Dashboard +- Not Started: GitHub to Azure Repos migration +### Web and Mobile Dev + +- Done CS - Set up project +- Done CS - Allocated Ben Stephens as admin +- Done CS - Added sprints for T1 2025 +- Done CS - Set Up Boards columns +- Done CS - Planner Migration (add planner tasks as user stories with checklist as tasks) +- Done CS - Embed Boards into Teams for T1 2025 instead of Planner. +- Not Started: Set up Dashboard +### Company Leaders + +- Done CS - Set up project +- Done CS - Allocated Ben Stephens as admin +- Done CS - Added sprints for T1 2025 +- Done CS - Set Up Boards columns +- Done CS – Used Board +## Start of Trimester 1, 2025 + +### For Mentors and Team Leaders + +- Mentors must be assigned to their Project Teams with at least Basic access. +- They must assign at least 1 leader in their team with Basic access. +- View the Welcome Wiki found in “Overview” > “Wiki”. +- Mentors/Student Leaders must consider whether you want 1 unified team, or separate sub-teams. +- Go to: + +![](img/Picture1.png) + +![](img/Picture2.png) + +- Then assign all Redback Operations students to their respective teams with Stakeholder access. Do this by clicking on the team’s name, then when you are in the team view click “Add”: + +![](img/Picture3.png) + +*If any of the student leaders need to make changes to project teams, they will need to seek approval from their mentor for basic access. + +Area paths have been set up, so team members should only see their own boards. + +Any perpetual informational tasks housed within the previous planner have been added to the Team Wiki which can be found within the Project space > Overview > Wiki. + +### For Team Members + +- Once you have been granted Stakeholder access to Azure DevOps login and navigate to your team Wiki. This can be found in the left-hand menu under Overview > Wiki. +- Read the Welcome Wiki understanding that some of this will already have been taken care of by your mentor or team leader. +- Once you have read through the welcome wiki go to Boards in the Boards menu in the left-hand pane. It's a good idea to review what was completed last trimester and any item sitting open or in the backlog. This may give you an idea of the direction that you may want to take your individual contribution in. +### For Everyone + +At the start of the trimester once the team have looked over the information from the previous trimester it is a good idea to move any complete items you no longer need to reference into the completed previous trimesters column. + +## During T1 2025 + +Here are some items you may want to consider moving into Azure DevOps in T1 2025, they were considered out of scope in T3 2024: + +- Move the OnBoarding process into Azure DevOps. +- Set up Power BI Integration so teaching team can audit activity utilising BI reports +- Set up integration with current GitHub repos so teams can start working natively within Azure DevOps. +- Consider full migration of your team’s GitHub repo into Azure Repos, this will create much better security around our dev pipelines. +## At the end of T1 2025 + +- You may want to set up sprints for the trimester ahead so they can get started quickly. +- Ensure your board is updated and items are moved through the swim lanes accurately reflecting progress. +- Update Welcome Wiki with any knew information that may be required following your own contribution to Azure DevOps. +- You may even want to update this quick start guide for the next cohort to get started quickly in the platform. diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Best Practice & Usage Guidelines.mdx b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Best Practice & Usage Guidelines.mdx new file mode 100644 index 000000000..ef08d5c3b --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Best Practice & Usage Guidelines.mdx @@ -0,0 +1,112 @@ +--- +sidebar_position: 4 +sidebar_label: Best Practice & Usage Guidelines +title: Best Practice & Usage Guidelines +description: Azure Boards Design & Usage Guidelines for Redback Operations +--- +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
VersionModified ByApproverDateChanges made
V1.0Daniel McAulayDaniel McAulay17/09/2024Document Creation
+
+ +
+ +## 6. Best Practices for Using Azure Boards + +To ensure the successful implementation and ongoing use of Azure Boards within the Redback Operations Cyber Security Team, it is essential to follow established best practices. These practices will help each team manage their tasks efficiently, maintain clear communication, and ensure that all projects are completed on time and to a high standard. + +
+ +### 6.1 Structuring Work Items + +Work items are the building blocks of Azure Boards, representing tasks, user stories, bugs, and other units of work that need to be tracked and managed. Properly structuring these work items is crucial for maintaining organization and clarity. + +![Work Items](/img/azure-boards-images/6-1-image.png) + +
+ +### 6.2 Task Assignment and Management + +Efficient task assignment ensures that work is distributed evenly across the team and that each task is handled by the most qualified team member. Proper management of these tasks is essential for maintaining momentum and avoiding bottlenecks. + +![Task Assignments](/img/azure-boards-images/6-2-image.png) + +
+ +### 6.3 Using Boards and Views Effectively + +Boards in Azure Boards provide a visual representation of the team's workflow, making it easy to track the progress of tasks and identify any bottlenecks. Configuring these boards to reflect the team's processes is essential for efficient management. + +![Boards and Views](/img/azure-boards-images/6-3-image.png) + +
+ +### 6.4 Managing Backlogs + +The backlog is a key component of Azure Boards, representing a prioritized list of work items that need to be addressed. Effective backlog management ensures that the most important tasks are completed first and that the team is always working on the highest-value activities. + +![Backlogs](/img/azure-boards-images/6-4-image.png) + +
+ +### 6.5 Sprint Planning and Execution + +Sprints are time-boxed periods during which specific tasks are completed. Effective sprint planning and execution ensure that the team is focused on achieving clear goals and that progress is made consistently. + +![Sprint Planning](/img/azure-boards-images/6-5-image.png) + +
+ +### 6.6 Utilizing Queries and Dashboards + +Queries and dashboards in Azure Boards provide tools for monitoring team performance, tracking key metrics, and gaining insights into project progress. Proper use of these tools ensures that the team can make informed decisions and identify areas for improvement. + +![Queries and Dashboards](/img/azure-boards-images/6-6-image.png) + +
\ No newline at end of file diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Conclusion.mdx b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Conclusion.mdx new file mode 100644 index 000000000..52890fe76 --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Conclusion.mdx @@ -0,0 +1,68 @@ +--- +sidebar_position: 9 +sidebar_label: Conclusion +title: Conclusion +description: Azure Boards Design & Usage Guidelines for Redback Operations +--- +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
VersionModified ByApproverDateChanges made
V1.0Daniel McAulayDaniel McAulay17/09/2024Document Creation
+
+ +
+ +## 9. Conclusion + +The implementation of Azure Boards within the Redback Operations Cyber Security Team represents a critical step in optimizing project management, enhancing collaboration, and improving task visibility across the organization. By configuring Azure Boards to meet the specific needs of each sub-team, this solution provides a tailored platform for managing workflows, tracking progress, and ensuring alignment with the company\'s broader cybersecurity goals. + +With features like custom boards, sprints, work item templates, and integrations with essential tools such as GitHub, SonarQube, Nagios, and SIEM systems, Azure Boards empowers each team to efficiently manage their tasks, streamline their workflows, and automate critical processes. The platform\'s ability to track incidents, code reviews, compliance audits, and infrastructure maintenance ensures that all aspects of Redback Operations\' cyber security efforts are properly managed and aligned with organizational priorities. + +By integrating best practices in task management, reporting, and sprint execution, this solution is expected to lead to increased efficiency, reduced operational risk, and improved collaboration between teams. The successful deployment of this design ensures that the Redback's Cyber Security Team is equipped to handle its responsibilities while maintaining the flexibility to evolve alongside the organization's needs. + +
\ No newline at end of file diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Cyber Security Team Use Cases & Examples.mdx b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Cyber Security Team Use Cases & Examples.mdx new file mode 100644 index 000000000..ef002b487 --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Cyber Security Team Use Cases & Examples.mdx @@ -0,0 +1,246 @@ +--- +sidebar_position: 3 +sidebar_label: Cyber Security Team Use Cases & Examples +title: Cyber Security Team Use Cases & Examples +description: Azure Boards Design & Usage Guidelines for Redback Operations +--- +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
VersionModified ByApproverDateChanges made
V1.0Daniel McAulayDaniel McAulay17/09/2024Document Creation
+
+ +
+ +## 5. Team-Specific Usage and Processes + +This section provides detailed guidance on how each sub-team within the Redback Operations Cyber Security Team will utilize Azure Boards. The focus is on aligning Azure Boards\' capabilities with the specific responsibilities and workflows of the SecDevOps, Blue Team, Infrastructure, Red Team, and GRC teams. + +By customizing Azure Boards for each team, Redback Operations aims to enhance collaboration, improve task management, and streamline the execution of security and IT operations. + +
+ +### 5.1 SecDevOps Team + +The SecDevOps team is responsible for integrating security into the software development lifecycle, automating security testing, and ensuring that secure coding practices are followed throughout the development process. Azure Boards will be used by the SecDevOps team to manage these activities efficiently. + +#### 5.1.1 Key Responsibilities + +- Managing CI/CD pipelines and ensuring security is integrated at every stage. + +- Conducting code reviews and automating security testing. + +- Overseeing the implementation of secure development practices. + +#### 5.1.2 Usage of Azure Boards + +*Task Management* + +The SecDevOps team will use Azure Boards to track tasks related to CI/CD pipeline configuration, security testing automation, and code reviews. Work items will be created for each task, with detailed descriptions, assigned team members, and due dates. + +##### CI/CD Pipeline Integration + +Azure Boards will be integrated with GitHub, allowing the SecDevOps team to link work items to specific commits, branches, and pull requests. This integration will help manage code reviews and ensure that security checks are performed before code is merged. + +##### Security Testing with SonarQube + +SonarQube will be integrated with Azure Boards to automate the process of scanning code for security vulnerabilities. Results from SonarQube scans will be linked to work items in Azure Boards, enabling the team to track and remediate issues efficiently. + +##### Sprint Planning + +Sprints will be used to manage the workload of the SecDevOps team. During sprint planning, tasks will be moved from the backlog into the sprint, prioritized based on their importance to ongoing projects. The sprint board will provide a visual representation of task progress, helping the team stay on track. + +##### Workflow Example + +A typical workflow for the SecDevOps team might involve creating a task for setting up a new CI/CD pipeline, linking it to a GitHub branch, and automating security tests using SonarQube. As the pipeline is configured, the task would move through stages like \"To Do,\" \"In Progress,\" and \"Completed,\" with code reviews and security checks being documented in Azure Boards. + +
+ +### 5.2 Blue Team + +The Blue Team is tasked with defending the organization's infrastructure against cyber threats. Their primary activities include monitoring for potential threats, responding to security incidents, and developing strategies to mitigate risks. Azure Boards will help the Blue Team manage these activities effectively. + +#### 5.2.1 Key Responsibilities + +- Monitoring and responding to security incidents. + +- Conducting threat hunting and proactive threat analysis. + +- Developing and implementing mitigation strategies for identified threats. + +#### 5.2.2 Usage of Azure Boards: + +##### Incident Response Management + +The Blue Team will use Azure Boards to track security incidents from detection through to resolution. Work items will be created for each incident, with detailed logs of the incident, steps taken during the investigation, and final resolution. + +##### SIEM Tool Integration + +Azure Boards will be integrated with SIEM tools, enabling the automatic creation of work items when security alerts are triggered. These work items will be prioritized and assigned to team members based on the severity of the incident. + +##### Threat Hunting + +Tasks related to threat hunting and analysis will be managed in Azure Boards. The Blue Team will document their hypotheses, findings, and any actions taken in response to potential threats. + +##### Vulnerability Management + +The Blue Team will track vulnerabilities identified through monitoring and threat analysis in Azure Boards. Each vulnerability will be logged as a work item, with details on the affected systems, severity, and recommended remediation steps. + +##### Workflow Example + +When a security alert is triggered by the SIEM system, a work item is automatically created in Azure Boards. The Blue Team investigates the incident, documents their findings, and takes appropriate actions to contain and mitigate the threat. The work item is then moved through stages like \"Detection,\" \"Investigation,\" \"Mitigation,\" and \"Resolution.\" + +
+ +### 5.3 Infrastructure Team + +The Infrastructure Team is responsible for managing and maintaining the organization's IT infrastructure, including systems administration, network management, and infrastructure support. Azure Boards will be used to organize and track these essential activities. + +#### 5.3.1 Key Responsibilities + +- Managing system administration tasks, including server maintenance and patch management. + +- Configuring and maintaining network devices, firewalls, and monitoring systems. + +- Ensuring the availability, security, and performance of IT infrastructure. + +#### 5.3.2 Usage of Azure Boards + +##### System Administration + +The Infrastructure Team will use Azure Boards to manage tasks related to server maintenance, user account management, and patch deployment. Each task will be logged as a work item, with details on the scope, timeline, and responsible team members. + +##### Network Management + +Tasks related to network configuration, firewall management, and system monitoring will be tracked in Azure Boards. For example, a task might be created for updating firewall rules or configuring a new VLAN, with progress tracked through different stages. + +##### Nagios Integration + +Nagios, used for system monitoring, will be integrated with Azure Boards to log alerts and issues as work items. This integration ensures that the team can respond quickly to any system outages or performance issues. + +##### Patch Management + +Azure Boards will help the Infrastructure Team manage the patching of servers, workstations, and network devices. Tasks will be created for each patch, with stages like \"Scheduled,\" \"In Progress,\" \"Testing,\" and \"Completed\" to track progress. + +##### Workflow Example + +A task is created in Azure Boards for a temperature alert in Nagios. The task is scheduled and moves through stages to alert the team and identify the cause behind the temperature warning. If Nagios detects any issues during or after the sensor is resolved, a new work item is created, and the Infrastructure Team is alerted to investigate and resolve the issue again. + +
+ +### 5.4 Red Team + +The Red Team focuses on identifying and exploiting vulnerabilities within the organization's systems to simulate real-world cyberattacks. This team's activities are crucial for testing and improving the organization's defenses. Azure Boards will be instrumental in managing their operations. + +#### 5.4.1 Key Responsibilities + +- Conducting penetration tests to identify security weaknesses. + +- Performing vulnerability assessments and recommending remediation actions. + +- Simulating real-world cyberattacks to test the organization's defences and validating incident response strategies. + +#### 5.4.2 Usage of Azure Boards: + +##### Penetration Testing + +The Red Team will use Azure Boards to manage and document their penetration testing activities. Each test will be tracked as a work item, with details on the scope, objectives, and findings. + +##### Vulnerability Assessment + +Vulnerabilities identified during tests or assessments will be logged as work items in Azure Boards. The Red Team will provide detailed descriptions of each vulnerability, including its severity and potential impact, and will track the remediation process. + +##### Integration with Testing Tools + +Tools like Kali Linux and Burp Suite will be used by the Red Team for testing, with results documented in Azure Boards. Work items can be linked to specific test cases or tools, providing a clear record of the testing process. + +##### Reporting and Collaboration + +After completing a test or assessment, the Red Team will use Azure Boards to generate reports and collaborate with other teams on remediation efforts. Work items related to remediation will be tracked and assigned to the appropriate teams. + +##### Workflow Example + +A penetration test is planned and documented as a work item in Azure Boards. The Red Team conducts the test using Kali Linux and Burp Suite, logging any vulnerabilities they discover. These vulnerabilities are then tracked through the remediation process, with detailed reports generated and shared with other teams. + +
+ +### 5.5 GRC Team + +The Governance, Risk, and Compliance (GRC) Team ensures that the organization adheres to industry standards, regulatory requirements, and internal policies. They manage compliance, risk assessments, and policy development. Azure Boards will help the GRC Team organize and track these activities. + +#### 5.5.1 Key Responsibilities + +- Conducting compliance audits and ensuring adherence to regulatory requirements. + +- Performing risk assessments and managing identified risks. + +- Developing and enforcing security policies and procedures. + +#### 5.5.2 Usage of Azure Boards: + +##### Compliance Audits + +The GRC Team will use Azure Boards to plan and execute compliance audits. Work items will be created for each audit, with details on the scope, standards being audited, and any findings that require attention. + +##### Risk Assessments + +Risks identified during assessments will be tracked as work items in Azure Boards. Each risk will include details on its likelihood, impact, and mitigation strategies, with ongoing monitoring and updates tracked in the system. + +##### Policy Development + +Tasks related to the development, review, and implementation of security policies will be managed in Azure Boards. Each policy will be tracked through stages from drafting to approval and implementation. + +##### Collaboration with Other Teams + +The GRC Team will work closely with other teams, such as Infrastructure and SecDevOps, to ensure that compliance and risk management efforts are aligned with operational practices. Azure Boards will be used to track these collaborative tasks and ensure that all teams are following the same guidelines. + +##### Workflow Example + +A compliance audit is scheduled and documented as a work item in Azure Boards. The audit is conducted, and any findings are logged as separate work items, with details on the required corrective actions. The GRC Team collaborates with the relevant teams to ensure that all compliance issues are addressed, tracking the progress of these efforts in Azure Boards. + +
\ No newline at end of file diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Glossary.mdx b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Glossary.mdx new file mode 100644 index 000000000..82a351d6e --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Glossary.mdx @@ -0,0 +1,124 @@ +--- +sidebar_position: 10 +sidebar_label: Glossary +title: Glossary +description: Azure Boards Design & Usage Guidelines for Redback Operations +--- +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
VersionModified ByApproverDateChanges made
V1.0Daniel McAulayDaniel McAulay17/09/2024Document Creation
+
+ +
+ +## 10. Glossary + +Provided in this section is a glossary of all relevant terms and object definitions. + +- **Area Path**\ + Defines the hierarchical structure within Azure Boards, representing teams or sub-teams. It helps organize and categorize work items based on team responsibilities. + +- **Epic**\ + A large body of work that encompasses multiple features or tasks. Epics represent significant initiatives or projects that are broken down into smaller, more manageable work items. + +- **Feature**\ + A specific function or deliverable derived from an epic. Features typically take a few sprints to complete and provide value to the project, such as a new security tool rollout or system upgrade. + +- **User Story**\ + A smaller, actionable work item that describes a specific requirement from the perspective of the end user. User stories are typically completed within a single sprint and contribute to a feature's completion. + +- **Task**\ + The smallest unit of work, which is used to track individual activities required to complete user stories or features. Tasks are assigned to team members and have detailed descriptions, deadlines, and priorities. + +- **Bug**\ + A work item representing a defect or issue that needs to be resolved. Bugs are identified during testing or operations and tracked until they are fixed. + +- **Board**\ + A visual interface within Azure Boards that displays work items in different columns, representing stages of progress (e.g., To Do, In Progress, Done). Each team has its own board to manage tasks and track work. + +- **Sprint**\ + A time-boxed iteration, typically two weeks long, in which a set of tasks or user stories are planned and completed. Sprints help teams prioritize work and meet project goals within a defined timeframe. + +- **Backlog**\ + A collection of work items (epics, features, user stories, and tasks) that have yet to be completed. The backlog is prioritized during sprint planning, and work items are pulled into the sprint based on priority. + +- **Work Item**\ + A general term for any unit of work in Azure Boards, including epics, features, user stories, tasks, and bugs. Work items are created, tracked, and completed by the teams. + +- **Swimlane**\ + A horizontal division on a board that separates work items by categories, such as priority, type, or other criteria. Swimlanes help teams visually organize tasks to focus on specific areas. + +- **Burndown Chart**\ + A graphical representation of the work remaining in a sprint, showing the progress towards sprint completion. It helps teams track whether they are on pace to finish their tasks. + +- **Pull Request**\ + A request made in GitHub to review and merge code changes into a repository. Pull requests are linked to work items in Azure Boards to track code reviews and approvals. + +- **CI/CD Pipeline**\ + The continuous integration and continuous deployment pipeline that automates the process of integrating code changes, running automated tests, and deploying applications. + +- **SonarQube**\ + A tool integrated with Azure Boards to automate security and code quality checks during development. It flags potential issues in the code, which are then logged as work items for remediation. + +- **Nagios**\ + An infrastructure monitoring tool integrated with Azure Boards to log system alerts and issues. + +- **Sprint Planning**\ + The process of reviewing the backlog and assigning work items to an upcoming sprint. Teams prioritize tasks and set sprint goals during these planning sessions. + +- **Retrospective**\ + A meeting held at the end of a sprint to review the team\'s performance, identify areas of improvement, and discuss what went well. Action items from retrospectives are often tracked as tasks in Azure Boards. + +- **Query**\ + A custom search filter in Azure Boards that allows users to display specific work items based on criteria such as priority, assignee, or due date. Queries can be saved and reused to track ongoing work. + +- **Dashboard**\ + A visual interface in Azure Boards that displays key metrics, such as task completion rates, sprint progress, or incident response status. Dashboards are customizable for different teams and stakeholders. + +
\ No newline at end of file diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Introduction & High Level Summary.mdx b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Introduction & High Level Summary.mdx new file mode 100644 index 000000000..14fe7058d --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Introduction & High Level Summary.mdx @@ -0,0 +1,236 @@ +--- +sidebar_position: 1 +sidebar_label: Introduction & High Level Summary +title: Introduction & High Level Summary +description: Azure Boards Design & Usage Guidelines for Redback Operations +--- +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
VersionModified ByApproverDateChanges made
V1.0Daniel McAulayDaniel McAulay17/09/2024Document Creation
+
+ +
+ +## 1. Executive Summary + +The Redback Operations Cyber Security Team is tasked with ensuring the security, compliance, and operational efficiency of the organization's IT infrastructure. To support these goals, the team is implementing Azure Boards as a central platform for managing tasks, tracking workflows, and enhancing collaboration across multiple sub-teams, including SecDevOps, Blue Team, Infrastructure, Red Team, and GRC. + +Azure Boards will serve as the foundation for streamlining project management and coordination among these teams. By integrating Azure Boards into the operations of each sub-team, Redback Operations aims to achieve better visibility into project initiatives, more effective management of tasks and deadlines, and improved alignment between teams. This implementation is expected to lead to increased efficiency, reduced operational risks, and a more streamlined approach for project management & operational support. + +The project will involve configuring Azure Boards to meet the specific needs of each sub-team, defining workflows and processes that align with their unique responsibilities, and integrating Azure Boards with existing tools and systems where necessary. The goal is to create a unified platform that supports the cybersecurity team's mission while allowing for flexibility and scalability as the company expands under future project initiatives. + +
+ +## 2. Solution Overview + +The scope of this solution covers the implementation of Azure Boards for the Redback Operations Cyber Security Team, focusing on its five main sub-teams: SecDevOps, Blue Team, Infrastructure, Red Team, and GRC. Each team has distinct responsibilities, and Azure Boards will be configured to support these responsibilities effectively. + +
+ +### 2.1 Solution Scope + +The solution scope includes: + +- Integration with Existing Tools. + +- Setup & Configuration Guides. + +- Team Specific Workflows. + +- Training & Documentation. + +- Best Practice Guidelines. + +![Overview](/img/azure-boards-images/1-1-summary.png) + +The Configuration of Azure Boards. Setting up area paths, work item types, boards, and sprints tailored to the needs of each team. This configuration will be designed to facilitate task management, workflow tracking, and project visibility. + +The project will not cover the development or modification of external tools, systems, or processes that are not directly related to Azure Boards. Additionally, the solution will not include the implementation of new cybersecurity tools or platforms beyond the integration with existing systems. + +#### 2.1.1 Integration with Existing Tools + +While the primary focus is on Azure Boards, the solution will support future integrations with key tools such as GitHub integration for code management & pull request tracking, SonarQube for security testing, and Nagios for system monitoring. These integrations will enhance the capabilities of Azure Boards, enabling seamless workflows across the teams. + +#### 2.1.2 Development of Team-Specific Workflows + +Customizing workflows within Azure Boards to align with the operational processes of each team. This includes defining stages for work items, setting up approval processes, and configuring notifications and alerts. + +#### 2.1.3 Implementation of Best Practices + +Establishing best practices for using Azure Boards, including guidelines for task creation, prioritization, and sprint management. These practices will help ensure consistent and efficient use of the platform across all teams. + +The successful implementation of this solution will result in a fully operational Azure Boards platform tailored to the needs of Redback Operations' Cyber Security Team, with the capability to manage and track all relevant tasks, projects, and workflows. This solution will also simplify the start of trimester onboarding experience for new company members (Junior Students) by consolidating tasks and workflows into a single pane of glass. + +
+ +## 3. Solution Components + +The implementation of Azure Boards for the Redback Operations Cyber Security Team involves several key components that will be configured to meet the specific needs of the various sub-teams. This section outlines these components, explaining their purpose and how they will be utilized within the broader solution. + +
+ +### 3.1 Azure Boards + +Azure Boards is the central platform that will be used to manage tasks, track progress, and facilitate collaboration across the SecDevOps, Blue Team, Infrastructure, Red Team, and GRC teams. Azure Boards offers a range of features that will be leveraged to ensure effective project management, including: + +![Boards](/img/azure-boards-images/1-2-boards.png) + +#### 3.1.1 Work Items + +Azure Boards supports different types of work items, such as Epics, Features, User Stories, Tasks, and Bugs. These work items will be customized for each team to reflect their specific needs and workflows. For example, the SecDevOps team might use Tasks to track specific security testing activities, while the GRC team might use Features to manage compliance audits. + +![Queries and Dashboards](/img/azure-boards-images/1-4-workitems.png) + +#### 3.1.2 Boards and Kanban Views + +Each sub-team will have its own board configured within Azure Boards. These boards will provide a visual representation of tasks and their progress, using columns to represent different stages of work (e.g., To Do, In Progress, Done). The Kanban view will help teams manage their workflows efficiently, ensuring that tasks move smoothly from one stage to the next. + +#### 3.1.3 Area Paths and Teams + +Area Paths in Azure Boards are used to define the hierarchical structure for organizing work items. Each sub-team within the Redback Operations Cyber Security Team will have its own dedicated area path, allowing them to focus on tasks specific to their responsibilities while keeping work items well-organized and separated from other teams. This structure ensures clear visibility into each team's work without unnecessary clutter, helping maintain focus on relevant tasks. + +Each sub-team will be assigned to its corresponding Area Path, which provides them with an isolated view of their tasks and workflows. + +#### 3.1.4 Sprints + +Sprints will be used by each team to plan and execute work within specific timeframes. Azure Boards' sprint planning tools will help teams prioritize tasks, allocate resources, and track progress against sprint goals. The sprint backlog will provide a clear view of upcoming work, while the sprint board will track tasks as they move through the workflow. + +![Sprints](/img/azure-boards-images/1-3-sprints.png) + +#### 3.1.5 Queries and Filters + +Azure Boards provides powerful query and filtering capabilities, allowing teams to create custom views of work items based on specific criteria. For example, the Infrastructure team might create a query to track all open patch management tasks, while the Red Team might filter work items by the severity of vulnerabilities identified during testing. These queries can be saved and reused, making it easy to monitor key metrics over time. + +#### 3.1.6 Dashboards and Reports + +Dashboards in Azure Boards will provide real-time insights into the progress of tasks and projects across the teams. Customizable widgets can be added to dashboards to display metrics such as task completion rates, sprint progress, and the number of open bugs. Reports generated from Azure Boards will be used to provide stakeholders with detailed updates on project status, team performance, and areas that may require attention. + +
+ +### 3.2 Area Paths and Cyber Security Team Layout + +Area paths in Azure Boards will be configured to represent each sub-team within the Redback Operations Cyber Security Team. This hierarchical structure will allow for clear organization and management of work items, ensuring that each team has a focused view of their responsibilities. + +#### 3.2.1 SecDevOps Area Path + +This area path will encompass all work related to continuous integration/continuous deployment (CI/CD) pipelines, security testing, and code reviews. The SecDevOps team's tasks will be tracked and managed within this area path, with specific work items tailored to their processes. + +#### 3.2.2 Blue Team Area Path + +The Blue Team's area path will focus on incident response, threat hunting, and vulnerability management. Tasks related to these activities will be organized under this area path, enabling the team to efficiently manage and respond to security threats. + +#### 3.2.3 Infrastructure Area Path + +This area path will cover system administration, network management, and infrastructure support tasks. The Infrastructure team will use this area to track maintenance activities, patch management, and the configuration of monitoring tools like Nagios. + +#### 3.2.4 Red Team Area Path + +The Red Team's area path will be dedicated to penetration testing, vulnerability assessments, and other offensive security activities. Work items in this area will help the Red Team plan, execute, and document their testing efforts. + +#### 3.2.5 GRC Area Path + +The GRC team's area path will include tasks related to compliance audits, risk assessments, and policy development. This area will ensure that the GRC team can manage and track their work effectively, while also collaborating with other teams on cross-functional initiatives. + +
+ +### 3.3 Work Item Types + +Azure Boards supports a variety of work item types and templates that will be customized for each team to reflect their specific workflows. These work item types are based on Agile project management objects. The main work item types that will be used include: + +#### 3.3.1 Epics + +Large bodies of work that can be broken down into smaller, more manageable pieces. Epics will be used to represent major projects or initiatives, such as the implementation of a new security framework or a comprehensive vulnerability assessment. + +#### 3.3.2 Features + +Represent a segment of work that delivers a specific functionality or value. Features are typically derived from epics and are completed within a few sprints. For example, a feature might represent the deployment of a new monitoring tool or the rollout of a security patch across all servers. + +#### 3.3.3 User Stories/Tasks + +The smallest units of work that are actionable and can be completed within a single sprint. User stories or tasks will be used to track specific activities, such as configuring a firewall rule or conducting a code review. + +#### 3.3.4 Bugs + +Defects or issues that need to be fixed. Bugs can be identified during testing or normal operations and will be tracked until they are resolved. Bugs will be linked to the appropriate tasks or features to ensure they are addressed promptly. + +Each team will have the ability to customize these work item types to fit their specific needs, ensuring that Azure Boards reflects the unique workflows and processes of the Redback Operations Cyber Security Team. + +
+ +### 3.4 Board Configuration + +Boards in Azure Boards will be configured to provide each team with a visual representation of their workflow. These boards will use columns to represent different stages of work, allowing teams to easily track the progress of tasks from start to finish. + +#### 3.4.1 Column Setup + +Columns will be customized for each team based on their workflow. The default layout is as shown below: + +![Example Column Setup](/img/azure-boards-images/column-setup.png) + +- Swimlanes can be added to boards to further organize tasks by category, priority, or other criteria. For example, the GRC team might use swimlanes to separate compliance audits from risk assessments, while the Red Team might use swimlanes to distinguish between different types of penetration tests. + +- As tasks progress, they will be moved across the board from one column to the next. This visual approach helps teams quickly assess the status of their work and identify any bottlenecks or delays. + +The board configuration for each team will be designed to reflect their unique workflows and processes, ensuring that Azure Boards supports their operational needs. + +
+ +### 3.5 Sprints and Iterations + +Sprints and iterations will be used by each team to plan and execute work within defined timeframes. Azure Boards provides tools for managing sprints, including sprint planning, backlog management, and sprint tracking: + +- During sprint planning, teams will move tasks from the backlog into the sprint, prioritizing work based on importance and urgency. Sprint goals will be set to ensure that the team remains focused on key objectives. + +- The sprint backlog will provide a clear view of the tasks that need to be completed within the sprint. Teams will use the sprint board to track the progress of these tasks and ensure that they are completed on time. + +- Azure Boards will generate burndown charts to track the team's progress against the sprint goals. These charts will help teams monitor their workload and adjust as needed to stay on track. + +Sprints will be an integral part of each team's workflow, helping them manage their work efficiently and deliver results within the required timeframe. + +
\ No newline at end of file diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Risk Assessment.mdx b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Risk Assessment.mdx new file mode 100644 index 000000000..0bae590d4 --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Risk Assessment.mdx @@ -0,0 +1,104 @@ +--- +sidebar_position: 6 +sidebar_label: Risk Analysis & Assessment +title: Risk Analysis & Assessment +description: Azure Boards Design & Usage Guidelines for Redback Operations +--- +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
VersionModified ByApproverDateChanges made
V1.0Daniel McAulayDaniel McAulay17/09/2024Document Creation
+
+ +
+ +## 8. Risk Management and Mitigation + +The following tables outline potential risks associated with the implementation and ongoing use of Azure Boards, along with corresponding mitigation strategies and contingency plans. + +
+ +### 8.1 Technical Risks + +| Risk | Description | Mitigation Strategy | Contingency Plan | +|-----------------------------|-------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------| +| Integration Issues | Challenges in integrating Azure Boards with existing tools like GitHub, SonarQube, Nagios, and SIEM systems. | Conduct thorough testing of integrations before full implementation. Resolve compatibility issues during testing. | Identify alternative tools or processes that can be used if integration fails. Provide training on the use of these alternatives. | +| Data Synchronization Errors | Errors in real-time synchronization between Azure Boards and integrated tools, leading to delays or inaccuracies. | Implement data backup and recovery plans. Regularly back up data from Azure Boards and integrated tools. | Establish procedures for restoring data quickly in the event of synchronization errors. Continuously monitor synchronization to detect issues early. | +| System Downtime | Unexpected downtime of Azure Boards or integrated tools, disrupting access to tasks and project timelines. | Plan and communicate scheduled maintenance windows. Implement data backup strategies to minimize the impact of downtime. | Develop an incident response plan for dealing with prolonged downtime, including steps to switch to alternative systems or manual processes. | + +
+ +### 8.2 Operational Risks + +| Risk | Description | Mitigation Strategy | Contingency Plan | +|-----------------------|--------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------| +| Resistance to Change | Team members may resist adopting Azure Boards, hindering full utilization of the platform. | Implement change management initiatives, including workshops and communication campaigns. Highlight the benefits of the platform. | Introduce a gradual rollout to allow teams to adapt incrementally. Provide one-on-one support for those struggling with the transition. | +| Learning Curve | Team members may face challenges in learning how to use Azure Boards effectively, leading to delays. | Develop targeted training programs tailored to each team's needs. Provide ongoing support during the adoption phase. | Offer refresher courses and additional resources for team members who need further assistance. Allow extra time for complex tasks during the learning phase. | +| Complex Configuration | Configuration of Azure Boards may be more complex and time-consuming than anticipated, delaying the project. | Allocate sufficient time for configuration in the project plan. Involve technical leads from each team in the configuration process. | Allow for phased deployment to address issues in stages. Set up dedicated troubleshooting sessions to resolve configuration challenges. | + +
+ +### 8.3 Security Risks + +| Risk | Description | Mitigation Strategy | Contingency Plan | +|---------------------------|-------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------| +| Access Control Weaknesses | Inadequate configuration of access controls may result in unauthorized access to sensitive information. | Implement strict role-based access controls (RBAC). Regularly review and update access permissions. | Regular audits of access controls to ensure compliance. Immediate remediation steps if unauthorized access is detected, including locking down affected accounts. | +| Data Exposure | Unintentional exposure of sensitive information, such as credentials, if improperly stored in Azure Boards. | Provide data sensitivity training to all team members. Establish guidelines for handling and storing sensitive information. | Implement monitoring to detect improper storage of sensitive data. Immediate corrective actions if data exposure occurs, including alerting affected parties. | +| Compliance Challenges | Ensuring compliance with industry regulations, particularly Australian data protection and privacy laws. | Work closely with the GRC team to ensure compliance. Conduct regular audits to verify that Azure Boards meets all regulatory requirements. | Develop a compliance incident response plan to address and rectify any violations quickly. Provide documentation to support regulatory audits. | + +
+ +### 8.4 Adoption and Usage Risks + +| Risk | Description | Mitigation Strategy | Contingency Plan | +|--------------------------------|-------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------| +| Inconsistent Usage | Teams may not consistently use Azure Boards as intended, leading to gaps in task tracking and project visibility. | Develop and distribute clear usage guidelines. Conduct regular reviews to ensure adherence to processes. | Schedule periodic reviews and adjustments to ensure consistent usage. Introduce reinforcement training for teams that show inconsistent usage patterns. | +| Over-Complication of Workflows | Workflows may become overly complicated, making it difficult for team members to follow processes efficiently. | Regularly review and simplify workflows based on feedback. Ensure workflows are aligned with team needs and operational goals. | Implement a feedback loop to continuously gather input from users and make adjustments. Use pilot testing before implementing major workflow changes. | +| Training and Onboarding Delays | New team members may require additional time and resources for training, delaying their ability to contribute. | Establish a proactive onboarding process with comprehensive training. Provide ongoing support and mentorship. | Allow for extended onboarding periods in project planning. Assign mentors to new team members to accelerate their learning and integration into the team. | + +
\ No newline at end of file diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Setup Guide & Implementation Plan.mdx b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Setup Guide & Implementation Plan.mdx new file mode 100644 index 000000000..80daca862 --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Setup Guide & Implementation Plan.mdx @@ -0,0 +1,300 @@ +--- +sidebar_position: 5 +sidebar_label: Setup Guide & Implementation Plan +title: Setup Guide & Implementation Plan +description: Azure Boards Design & Usage Guidelines for Redback Operations +--- +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
VersionModified ByApproverDateChanges made
V1.0Daniel McAulayDaniel McAulay17/09/2024Document Creation
+
+ +
+ +## 7. Implementation Plan + +The Implementation Plan outlines the step-by-step process for setting up Azure Boards for future Redback Operations project teams. This plan is designed as a blueprint for designing/creating your own project team, sub-teams, boards and integrations etc. + +While this implementation plan is designed for the Redback Cyber Security team, other project teams can follow these instructions and modify the relevant steps for their own purposes. + +
+ +### Step 1: Initial Setup and Project Creation + +1. **Create the Azure Boards Project:** + + - Set up the project named **Redback Operations Cyber Security Team**. + + - Choose **Git** for version control and **Agile** for the work item process. + + - Keep the project visibility **Private** until the structure and permissions are fully configured. + +2. **Define Area Paths for Sub-Teams:** + + - Create area paths under **Project Settings** \> **Areas** for: + + - SecDevOps + + - Blue Team + + - Infrastructure Team + + - Red Team + + - GRC Team + + - This ensures tasks are organized and aligned with each team's specific responsibilities. + +3. **Assign Teams to Area Paths:** + + - Create separate teams for each sub-group in **Project Settings** \> **Teams**. + + - Assign each team to the corresponding area path to give them autonomy in managing their tasks, while maintaining visibility across the organization. + +4. **Permissions and Access Control:** + + - Grant access based on the role and team assignment, ensuring only authorized team members can access their specific areas. + + - Review **role-based access control (RBAC)** policies to maintain data security and ensure proper task visibility within and across teams. + +
+ +### Step 2: Configure Boards for Each Sub-Team + +1. **Create Custom Boards for Each Team:** + + - Configure custom boards for each team to reflect their workflows. + + - Columns to include: **To Do**, **In Progress**, **Review**, and **Done**. + + - Adjust columns based on team workflows, adding categories like \"Testing\" or \"Waiting for Approval\" as needed. + +2. **Use Swimlanes to Categorize Work Items:** + + - SecDevOps: Separate tasks by security testing, code reviews, and pipeline automation. + + - Blue Team: Categorize by incident response priority and threat-hunting activities. + + - Infrastructure: Differentiate between network management, server patching, and user management. + + - Red Team: Split tasks for internal/external pentesting and vulnerability assessments. + + - GRC Team: Organize tasks by compliance audits, risk assessments, and policy development. + +3. **Visual Workflow Tracking:** + + - Ensure each team\'s board provides a clear visual representation of their work items moving through stages. + + - Use **work item rules** to automatically transition tasks to the next stage based on completion criteria (e.g., after a code review or security test). + +
+ +### Step 3: Set Up Work Items and Task Templates + +1. **Define Work Item Types:** + + - For each team, define custom **Epics**, **Features**, **User Stories**, **Tasks**, and **Bugs**. + + - Create work item templates for recurring tasks such as penetration testing, security audits, code reviews, and infrastructure patching. + +2. **Create Task Templates:** + + - Standardize task creation with predefined templates for: + + - SecDevOps: CI/CD pipeline setup, automated code scanning, and deployment validation. + + - Blue Team: Incident response, security alerts, and monitoring. + + - Infrastructure: Firewall configuration, patch deployment, and system monitoring with Nagios. + + - Red Team: Penetration test scheduling, vulnerability documentation, and follow-up tasks for mitigation. + + - GRC Team: Policy drafting, compliance audits, and risk reporting. + +3. **Assign Priorities and Dependencies:** + + - Assign priority levels to tasks based on urgency, with **critical tasks** marked for immediate attention. + + - Link related work items to reflect dependencies (e.g., a vulnerability task that depends on a successful pentest). + +4. **Use Automation for Recurring Tasks:** + + - Set up automation to create recurring tasks at the start of each sprint, ensuring workflows like security audits or patch cycles are consistently executed. + +
+ +### Step 4: Sprint Setup and Backlog Management + +1. **Configure Iterations (Sprints) for Each Team:** + + - Create sprints under Project Settings \> Iterations with a typical two-week cycle (e.g., Sprint 1, Sprint 2). + + - Assign these sprints to each sub-team to provide clear timelines and deliverable tracking. + +2. **Backlog Setup and Prioritization:** + + - Organize each team's backlog into Epics, Features, and Tasks. + + - During sprint planning, the team leads will prioritize tasks and move them into the sprint backlog, ensuring alignment with sprint goals. + + - Large tasks (Epics) should be broken into smaller tasks to fit within the sprint timeframe. + +3. **Track Sprint Progress:** + + - Monitor team progress via the sprint board, ensuring that work items move fluidly across stages. + + - Use burndown charts to visualize task completion and remaining workload, adjusting workloads as necessary to avoid sprint overrun. + +4. **Automated Notifications for Sprint Deadlines:** + + - Set up alerts for nearing sprint deadlines or overdue tasks to ensure team members complete work on time and adjust as necessary. + +
+ +### Step 5: Integration with External Tools + +1. **Integrate GitHub with Azure Boards:** + + - For SecDevOps and Red Team, integrate GitHub with Azure Boards to track commits, pull requests, and code reviews directly from the board. + + - Link work items to specific code branches and ensure that pull requests undergo automated security testing. + +2. **SonarQube Integration (SecDevOps Team):** + + - Automate security checks by integrating SonarQube with Azure Boards, allowing results from security scans to be captured as work items for review and remediation. + + - Set up alerts and notifications to track code quality issues automatically. + +3. **Nagios Integration (Infrastructure Team):** + + - Integrate Nagios alerts with Azure Boards so that system incidents (e.g., server downtime or network issues) are automatically created as tasks for the Infrastructure team. + +4. **SIEM Tool Integration (Blue Team):** + + - Integrate SIEM tools with Azure Boards to automate incident creation when security threats are detected. This allows the team to manage and respond to threats in real-time from a central location. + +
+ +### Step 6: Onboarding Process for New Students + +1. **Create Onboarding Tasks for New Students:** + + - Set up an onboarding task list for each new student joining the team. Tasks will include company registration, GitHub access, and reviewing the Azure Boards project. + + - Use the WorkItem Clone tool to replicate these tasks each trimester for new student onboarding. + +2. **Assign Sub-Team Responsibilities:** + + - Based on the team they are joining (SecDevOps, Blue Team, etc.), students will be assigned relevant onboarding tasks and introduced to project documentation. + + - Each student should also review previous sprint goals and completed tasks to familiarize themselves with ongoing work. + +3. **Onboarding Materials:** + + - Provide access to user guides, video tutorials, and team-specific documentation to help new students understand how to use Azure Boards. + + - Mentorship assignments for each student will provide additional guidance during the onboarding period. + +
+ +### Step 7: Monitoring, Queries, and Reports + +1. **Custom Queries for Each Team:** + + - Set up queries to track important work items, such as open tasks, high-priority bugs, or tasks nearing deadlines. + + - For example: + + - Blue Team: Track security incidents by severity. + + - Infrastructure Team: Query open patch management tasks. + + - SecDevOps: View code reviews pending approval or sitting in backlog. + +2. **Build Dashboards:** + + - Create real-time dashboards for each team, displaying metrics such as task completion rates, sprint progress, and backlog health. + + - Customize dashboards to meet the needs of different stakeholders, providing insights into ongoing projects and team performance. + +3. **Automate Reports:** + + - Set up automated reports in Azure Boards to provide weekly or sprint-end summaries for stakeholders. Reports should cover metrics such as: + + - Sprint completion percentages + + - Outstanding incidents or vulnerabilities + + - Security testing results (SecDevOps) + + - Audit and compliance status (GRC Team) + +4. **Review and Optimize Workflows:** + + - Conduct post-sprint retrospectives with each team to review successes and areas for improvement. + + - Document feedback in Azure Boards as actionable items for future sprints. + +
+ +### Step 8: Final Testing and Support + +1. **Pilot Testing with Teams:** + + - Before fully rolling out Azure Boards to all sub-teams, conduct a pilot test with one team (e.g., SecDevOps). Gather feedback on the workflow, task tracking, and integrations. + + - Use the results to refine the setup for other teams and make any necessary adjustments to the board configurations, sprint structures, or task templates. + +2. **Continuous Monitoring:** + + - Use Analytics Views to monitor team performance and workload distribution across all sprints. + + - Regularly evaluate the use of Azure Boards to identify areas for improvement, such as optimizing task prioritization or enhancing dashboard functionality. + +
\ No newline at end of file diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Solution Architecture.mdx b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Solution Architecture.mdx new file mode 100644 index 000000000..1ee705913 --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Solution Architecture.mdx @@ -0,0 +1,144 @@ +--- +sidebar_position: 2 +sidebar_label: Solution Architecture +title: Solution Architecture +description: Azure Boards Design & Usage Guidelines for Redback Operations +--- +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
VersionModified ByApproverDateChanges made
V1.0Daniel McAulayDaniel McAulay17/09/2024Document Creation
+
+ +
+ +## 4. Solution Architecture + +The Solution Architecture section provides a detailed overview of how Azure Boards will be implemented and integrated into the existing infrastructure. This section will describe how the different components of Azure Boards interact with each other and how they integrate with the tools and systems currently in use by the various sub-teams. The goal is to create a cohesive, efficient, and scalable architecture that supports the cybersecurity objectives of the organization. + +
+ +### 4.1 Overview of the Architecture + +The architecture of the Azure Boards implementation is designed to provide a centralized platform for managing tasks, tracking progress, and facilitating collaboration across all sub-teams. Azure Boards will serve as the backbone of project management, ensuring that all teams can work cohesively while maintaining visibility into their specific responsibilities. + +Each sub-team---SecDevOps, Blue Team, Infrastructure, Red Team, and GRC---will have dedicated area paths within Azure Boards, allowing them to manage their workflows independently while still being part of the larger organizational structure. The architecture is designed to be modular, enabling easy customization and scalability as the organization grows or as team requirements change. + +
+ +### 4.2 Integration with Existing Tools + +While Azure Boards will be the primary platform for task management, it will also be integrated with several key tools that are already in use at Redback Operations. These integrations will ensure seamless workflows and enhance the capabilities of Azure Boards. + +#### 4.2.1 GitHub Integration + +Azure Boards will be integrated with GitHub, allowing the SecDevOps and Red Teams to link work items with specific commits, branches, and pull requests. This integration will facilitate code reviews, track development progress, and ensure that all code changes are tied to specific tasks or user stories. + +#### 4.2.2 SonarQube Integration + +For the SecDevOps team, SonarQube can be integrated with Azure Boards to automate code quality inspections. This integration will allow security checks to be part of the continuous integration/continuous deployment (CI/CD) pipeline, with results being tracked as work items in Azure Boards. + +#### 4.2.3 Nagios Integration + +The Infrastructure team can use Nagios for system monitoring, with alerts and notifications being integrated into Azure Boards. This setup will ensure that any issues detected by Nagios are automatically logged as work items, allowing the team to respond quickly to system outages or performance degradation. + +#### 4.2.4 SIEM Tools Integration + +The Blue Team can integrate Azure Boards with Security Information and Event Management (SIEM) tools. This integration will ensure that security incidents detected by the SIEM tools are logged as work items in Azure Boards, allowing the Blue Team to manage and track the incident response process effectively. + +
+ +### 4.3 Data Flow and Interaction + +The data flow within the Azure Boards architecture is designed to be straightforward and efficient, ensuring that all teams can access the information they need while maintaining clear boundaries between different areas of responsibility. + +#### 4.3.1 Work Item Management + +All tasks, user stories, and other work items will be created, managed, and tracked within Azure Boards. Each work item will be associated with a specific area path, ensuring that it is visible only to the relevant team. Work items can be linked to specific commits, pull requests, or other external data sources as needed. + +#### 4.3.2 Boards and Sprints + +Each team will have its own board within Azure Boards, configured to reflect its specific workflow. Work items will move through the board as tasks progress, providing a visual representation of the team\'s work. Sprints will be used to manage work within specific timeframes, with burndown charts and other tools providing real-time insights into progress. + +#### 4.3.3 Notifications and Alerts + +Azure Boards will be configured to send notifications and alerts to team members based on specific triggers, such as the creation of a new work item, the movement of a task to a different stage, or the detection of a security incident. These notifications will ensure that team members are always aware of important developments. + +#### 4.3.4 Reporting and Dashboards + +Data from Azure Boards will be used to generate reports and dashboards that provide insights into team performance, project progress, and overall security posture. These reports can be customized to meet the needs of different stakeholders, ensuring that everyone has the information they need to make informed decisions. + +
+ +### 4.4 Scalability and Flexibility + +The architecture of the Azure Boards implementation is designed to be both scalable and flexible, allowing Redback Operations to adapt to changing requirements over time. + +As the organization grows, new teams can be added to Azure Boards by creating additional area paths and configuring new boards. The architecture supports the addition of new work item types, workflows, and integrations as needed, ensuring that Azure Boards can continue to meet the organization\'s needs. + +The modular design of the architecture also allows for easy customization of boards, workflows, and work item types. Teams can adjust their configurations based on evolving requirements, without affecting other teams or disrupting ongoing work. + +
+ +### 4.5 Security Considerations + +Given the sensitive nature of the work carried out by the Cyber Security Team, security is a key consideration in the design of the Azure Boards architecture. + +#### 4.5.1 Access Control + +Access to Azure Boards will be tightly controlled, with permissions configured to ensure that team members can only view and interact with work items relevant to their responsibilities. This will be managed through role-based access control (RBAC), with different roles assigned based on team membership and job function. + +#### 4.5.2 Data Protection + +All data within Azure Boards will be protected by encryption, both at rest and in transit. Integration with other tools will be secured through encrypted communication channels, and sensitive information (such as credentials or personal data) will be handled in accordance with Redback Operations\' data protection policies. + +#### 4.5.3 Audit and Compliance + +Azure Boards will be configured to provide audit logs that track all significant actions, such as the creation or modification of work items, changes to access permissions, and integration with external tools. These logs will be used to ensure compliance with internal and regulatory requirements. + +
\ No newline at end of file diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Technical Use Guide.mdx b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Technical Use Guide.mdx new file mode 100644 index 000000000..bf9b6bb19 --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/Technical Use Guide.mdx @@ -0,0 +1,155 @@ +--- +sidebar_position: 8 +sidebar_label: Technical Use Guide +title: Technical Use Guide +description: Guide to using the technical features of Azure DevOps. +--- +--- +
+ + + + + + + + + + + + + + + + + + + +
VersionModified ByApproverDateChanges made
V1.0Codey FunstonCodey Funston01/01/2025Document Creation
+
+ +
+ +## Support +> Have a question or issue you would like help with +> in Azure DevOps? +> Contact support. \ +> \* Support queries will be available in semester 1 of 2025 only. + +## Introduction +Azure DevOps (ADO) gives you a lot of technical control through GUI-based +configuration and a highly documented API. During this semester (T3 2024) +we trialed key technical features for a single team in a project, the +SecDevOps team. The following was trialed: + +1. [User Dashboards](#creating-custom-user-dashboards) +2. [GitHub Connections](#connecting-to-github) +3. [API Calls through GitHub Actions](#api-calls-and-github-actions) +4. [Basic Queries](#use-of-custom-queries) + +**The following documentation gives a brief overview of those areas. The main +guide is a video playlist available here:** + + +
+ +## Creating Custom User Dashboards + +Below is how the dashboard that we tested turned out. It was designed to +fit nicely on devices with screens as small as 13"/14". It is structured +to show the most important information first, and quickly. With the +elements not visible until scrolling having less importance, and not being +key information sources for project insight. + +#### _Dashboard at Login_ +![no-scroll-dashboard-view](/img/azure-boards-images/tech-use-guide/no_scroll.png) + +#### _Dashboard After Page Scroll_ +![no-scroll-dashboard-view](/img/azure-boards-images/tech-use-guide/scrolled_down.png) + +The widgets on screen are a mix of pre-built ones by Microsoft, such as the work assigned +at the top left, and markdown pages such as the task creation templates one below. A burnup +chart was chosen for showing progress against project scope as it is better for reducing +stress in a team with its focus on progress instead of work to do. +If you look at the top right of the screen in the dashboard at login you will se three +blocks with colours indicating their state. These colours can be customised by editing +the widgets and adding your own "levels of severity". Note that there is a default colour +and that the rules have precedence based on their order from top to bottom. + +![no-scroll-dashboard-view](/img/azure-boards-images/tech-use-guide/colour_rules.png) + +### Pull Request View +An important part of the dashboard for the DevSecOps (the team that the trial was for) +is the pull requests (PR's) view. It is built on a custom query that selects tasks in the current +semester that are in the PR's area path. These tasks are automatically created +through GitHub actions which is mostly covered in the video walkthrough. The goal of creating the automation and +view in the dashboard was to join code reviews and project management into one thing. +It means that team leaders can automatically assigned PR's to team members based +on repository preferences, then manage their completion. And, team members can ensure +that they don't forgot to review any PR's as they are part of their main project management +suite. + +#### _Pull Request Dashboard View_ +![no-scroll-dashboard-view](/img/azure-boards-images/tech-use-guide/pr_view.png) + +
+ +## Connecting to GitHub +Setting up a reference to GitHub is relatively straightforward. To do so follow these steps: + +### _In GitHub_ +1. Go to the repository that you want to connect. +2. Ask your team leader to add you as a "direct access" member. For team leaders, +access this through **Repository Settings >> Collaborators and teams >> Manage access >> Direct access.** +3. Now you need to generate a personal access token (PAT) through your user account settings. Go to +**Settings >> Developer Settings >> Personal access tokens >> Tokens (classic) >> Generate new token.** +4. Make sure that the token has the following, and only the following, permissions: + +
    +
  1. repo
    2. +
  2. admin:repo_hook
    3. +
  3. read:user
    4. +
  4. user:email
    5. +
+ +### _In ADO_ +1. Go to **Project Settings >> Boards >> GitHub connections.** +2. Click "New connection" +3. Either paste your PAT or import it from a secure password manager. +4. Click **Connect**. + +This will allow you to create new branches for tasks, or link tasks to existing +commits, PR's, or branches. Note that this is not related to the "Repos" service +in ADO as this can only copy the GitHub repo and then host it separately. As of +writing this (January 2025) we are not planning on using this tool for repository +hosting. + +
+ +## API Calls and Github Actions + +The documentation for the part of the API that we tested is hosted by Postman +[here](https://documenter.getpostman.com/view/40407894/2sAYJ7hzSB). +We don't go into the API very much aside from that website and a bit in the +video walkthrough. It is better to go to Microsoft's official documentation +as it is a large API and any small syntax or logic errors can result in **a lot** +of troubleshooting (from experience). Therefore, you should go to the +[source](https://learn.microsoft.com/en-us/rest/api/azure/devops/?view=azure-devops-rest-7.2). + + +
+ +## Use of Custom Queries +Azure DevOps gives you an easy to use query editor. As pictured below you add fields +to check for, a logical operator for comparison, and the value. It is good practice +to have the following clause in all queries so that anything in the current semester +is returned. More detail is included in the video demonstration. + +` Changed Date > @Today - 100 ` + +#### _Query To Select PR's_ +![no-scroll-dashboard-view](/img/azure-boards-images/tech-use-guide/pr_view_query.png) + +
\ No newline at end of file diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/_category_.json b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/_category_.json new file mode 100644 index 000000000..f2f27c62c --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/_category_.json @@ -0,0 +1,8 @@ +{ + "label": "Project Management - Azure Boards", + "position": 103, + "link": { + "type": "generated-index", + "description": "The following documentation is a reference for Project Leaders and team members on how to use Azure Boards for future project management & worklow management. Note that while this work primarily focuses on use cases for the Cyber Security team, other project teams can utilize this documentation to build their own project dashboards and workflows." + } +} diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/img/Picture1.png b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/img/Picture1.png new file mode 100644 index 000000000..e8bfeef8d Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/img/Picture1.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/img/Picture2.png b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/img/Picture2.png new file mode 100644 index 000000000..5afa8b360 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/img/Picture2.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/img/Picture3.png b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/img/Picture3.png new file mode 100644 index 000000000..ca25d91cf Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/Azure Boards Project Management/img/Picture3.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/Coding Best Practices/Introduction.md b/docs/cybersecurity/SecDevOps Team/Archived Files/Coding Best Practices/Introduction.md new file mode 100644 index 000000000..e4b42a0ed --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/Coding Best Practices/Introduction.md @@ -0,0 +1,24 @@ +--- +sidebar_position: 1 +--- + +# Introduction + +Introduction to the module and the contents within: + +::: Info +Author: **Lachlan Harrison**, **03/05/2025** +::: + +## Introduction to Module: +The following module will hopefully aim to inform the reader about a variety of concepts in the coding world ranging from code smells, best practice methods to reviewing our own code. All of these concepts will be supplied by coding examples in different coding languages and also opportunities to learn from the information supplied to then apply to future programs. + +Throughout the module you will learn about Code Smells and what they are and how to refactor them to avoid the smells appearing in your programs. Coding best practices is also covered along with discussing what we can achieve when we put these into practice. After this the module then showcases a video in which we go through 2 examples of coding and what we need to be aware and look out for when conducting code reviews. Finally the last section of the module contains a quiz for individuals to compile the knowledge they have gained from the module into practical questions to test their understanding and finish the module feeling confident with what they have learnt. + +### Contents: +The module is constructed with a number of sections including: +- **Introduction** You are here +- **Section 1:** CODE SMELLS +- **Section 2:** CODING BEST PRACTICES +- **Section 3:** CODE REVIEWING +- **Section 4:** QUIZ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/Coding Best Practices/Section1.md b/docs/cybersecurity/SecDevOps Team/Archived Files/Coding Best Practices/Section1.md new file mode 100644 index 000000000..d658a145c --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/Coding Best Practices/Section1.md @@ -0,0 +1,111 @@ +--- +sidebar_position: 2 +--- + +# **Section 1 - Code Smells** + +This section looks at various types of code smells that may arise when coding. + +::: Info +Author: **Lachlan Harrison**, **03/05/2025** +::: + +Code smells? It can happen, not literally though we can detect these "smells" within a developers code. Code smells are often indications of problems/violations within a developer’s design of their code that are present even when the code is deemed functional. They are not bugs or errors but are observable violations of code design. This section of the module will aim to assist you in learning about these various code smells, how they arise and what we can do to mitigate them. There are three main Code smells in which we will be looking at, these include Bloaters, Change Preventers and Dispensables. (For the purposes of understanding, we will mostly be focusing on bloaters and dispensables) + +## **BLOATERS:** +The first of the code smells categories falls under Bloaters: These are often referred to as Code, functions and classes that are so large that they become harder to work with. These can often accumulate over time as programs evolve. Within bloaters some causes of this smell arise from – Long methods, large classes, long parameter lists, Data clumps and Primitive obsession. (For our demonstration, we will focus on long methods, large classes and long parameter lists.) +``` +//Example of what this can look like (Python) +def large_function(data, parameter2, parameter3, parameter4, parameter5, parameter6) +{ + if(data == null) + { + return 0 + } + calculate_average = sum(data)/2 + print(calculate_average) + data_min = min(data) + data_max = max(data) + range = data_max - data_min + print(range) + data_sum = sum(data) + print(f"Sum of data: {data_sum}") +} +dataset = [0, 1, 2, 3, 4, 5] +large_function(dataset) +``` + +``` +//How we can minimise bloaters (Python) +def small_function(data) +{ + if(data == null) + { + return 0 + } + average = sum(data)/2 + print(average) +} +def range_function(data) +{ + range = max(data)-min(data) + print(range) +} +dataset = [0, 1, 2, 3, 4, 5] +small_function(dataset) +range_function(dataset) +``` + +### **CHANGE PREVENTERS:** +This relates to changing something in one place but then we must make various changes across the code. This can further complicate our code and make it less readable and less consistent. Some causes of these Change Preventers include Divergent Change, Shotgun Surgery and Parallel Inheritance Hierarchy. (This code smell is not a main focus for this module although the provided resource will allow for further investigation into this particular smell) +More can be explored via this link: https://refactoring.guru/refactoring/smells/change-preventers + + +## **DISPENSABLES:** +This can occur at any point throughout coding and this code smell relates to something that is unneeded in which when we refactor these, we can make the code become cleaner, efficient and easier to read. This smell can arise from many different factors in which we will go through in our examples. Dispensables is a very common code smell to occur in development. These involve Comments, duplicate code, data classes, dead code, lazy classes and speculative generality. (For our demonstration, we will focus on comments, duplicate code and dead code.) +``` +//Some examples of dispensables (HTML) + + +

Hello World!

+ + + +``` + +``` +//How we can minimise dispensables (HTML) + + +

Hello World!

+ + + +``` diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/Coding Best Practices/Section2.md b/docs/cybersecurity/SecDevOps Team/Archived Files/Coding Best Practices/Section2.md new file mode 100644 index 000000000..135778d34 --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/Coding Best Practices/Section2.md @@ -0,0 +1,217 @@ +--- +sidebar_position: 3 +--- + +# **Section 2 - Coding Best Practices** + +This section explains a variety of coding best practice methods that we can try and apply to our work to achieve a variety of goals. + +::: Info +Author: **Lachlan Harrison**, **03/05/2025** +::: + +On top of mitigating the code smells, we also need to ensure that we are also implementing some coding best practices to avoid security vulnerabilities and ensure that our code is appropriately utilized. Having these standards matter as it achieves numerous accomplishments including: + +- ***Consistency:*** We can ensure uniformity across codebases which makes it easier for developers to read, understand and maintain our code. Applying the same concepts throughout our code effectively being concise. + +- ***Readability:*** Having well-defined standards can reduce errors raised and improves collaboration within the team as everyone is able to easily read the code. + +- ***Error Prevention:*** With consistent practices, we can catch some common mistakes early reducing the risk of bugs being existent and improving our coding quality. + +- ***Scalability:*** Adhering to our best standards ensures our code can scale without becoming unmanageable. In other words, we can keep our performance in mind while coding and deliver a solution with good performance throughout the coding process. + +- ***Cross-Team Collaboration:*** We can facilitate collaboration among developers especially in large teams. For example, Redback Operations being a large team and collaborating on various coding projects. Any member can look at your code, understand what is occurring and even contribute to the solution. + +- ***Code Reviewing:*** An important aspect of this module, code reviews provide a clear criterion which can lead to effective feedback and refactoring of code in which we can then simplify our code. (This will be a dedicated section further in the module) + +- ***Efficient Maintenance:*** Following our standards will simplify the debugging process within our coding alongside refactoring and maintenance tasks for our projects. + + +Within this section of the module, we will briefly go through some various methods in which we can implement to our own coding to achieve the above accomplishments. + + +#### 1. **Have security and privacy considerations:** +With constant threats emerging, we want to mitigate any risk of any potential compromise. In saying this, having security considerations is of extreme importance and needs to always be implemented within our code. Some things we should not be doing at all, and this also comes with our code reviewing is: + +- **NO** Hardcoded passwords +- **NO** Hardcoded usernames +- **NO** Sensitive data coded or listed + +These three main points are a definite ‘no-go’ within coding as these can be easily leveraged against us and can often lead to attacks against our systems and unauthorised access. After all, most cyber security incidents are often caused by human error, so mitigating this risk can drastically reduce the likelihood of a compromise leading to an incident. These also come from secure coding practices including studying and analysing the OWASP Top 10, MITRE ATT&CK Framework, Cryptography Measures (Encryption/Decryption) and Security by design. Some resources will be provided for further information: + +- **OWASP Top 10:** https://owasp.org/www-project-top-ten/ +- **MITRE:** https://attack.mitre.org/ + +The main priority with this coding standard is that we should always be thinking about security considerations while completing our work, not have it as an afterthought. +Always keep a tight security posture and always question to yourself, “Am I giving away any sensitive information in this file?” + + +#### 2. **Focus on Code readability:** +With code readability, there are various elements in which we can incorporate with our coding to improve the readability of the code in which can be very useful and simple to implement. These tactics involve: Writing as few lines as possible within our code, utilizing appropriate naming conventions, segment our blocks of code in the same section into paragraphs, utilizing indentation to mark the beginning and end of our control structures, not using lengthy functions as a single function should carry out a single task (this falls into the bloater code smell), using the DRY principle (Don’t Repeat Yourself), automate repetitive tasks whenever possible and avoiding long lines of code. +Some examples of this include: +``` +//Hard to read code: (C#) +public void hardToReadCode(num, start, end) +{ +int mid=start+end/2; +if num==null return null; +else result = mid+num*2; +return result; +} +``` +``` +//More readable code: (C#) +public void easierToReadCode(num, start, end) +{ + int mid = start+end/2; + if num == null + { + return null; + } + else + { + result = mid+num*2; + return result; + } +} +``` +- With indentations in this example we are able to easier identify elements within a function. Readability is the key focus for this outcome! + + +#### 3. **Having meaningful names:** +We can utilize lots of different naming conventions within our coding and keep it consistent throughout a file. (As every file is different, some users may prefer one method to another.) We typically always stick to these naming conventions as it can achieve a variety of our outcomes listed above in particular readability and consistency. +These naming conventions can be further elaborated into four main conventions: + +- **Camel Case:** We start the name with a lowercase letter, if the name has multiple words, these words start with capital letters. This convention is typically utilized in JavaScript and even C# environments. +``` +public void findMaxValue(); +``` + +- **Snake Case:** We start the name with a lowercase letter, if the name has multiple words, these words start with a lowercase also and are separated with a ‘_’. This convention is typically utilized in Python environments. +``` +Int student_member_number = 42; +``` + +- **Kebab Case:** This is similar to the snake case except instead of using ‘_’ we utilise ‘-‘. This convention is typically utilized within HTML and CSS environments. +``` +get-user-input(); +``` + +- **Pascal Case:** Also known as Upper Camel Case, we start with a capital letter, if the name has multiple words, these all start with capital letters. This convention is typically utilized in C#, Python and JavaScript environments. +``` +int StudentMemberNumber = 42; +``` + +To summarise, when selecting a naming convention, use it throughout the entirety of developing your code and try to minimise switching throughout the project. Consistency and Readability are key here! + + +#### 4. **Avoid the use of a single identifier for numerous purposes:** +Throughout our projects, we should always assign unique variable names to avoid any overlap! Especially minimise the use of global identifiers unless required as these can lead to confusion, unintended behaviour when running our programs and potential bugs within the project itself. This falls under efficient maintenance and error prevention especially if we can detect these issues early! +``` +//An example of a single identifier (C#) We want global to stay as 10: +int global = 10; +public void LocalIdentifier() +{ + int local = global*2; + global = 20; //We can easily change the global variable as it is a global variable hence the variable not needing to be initialised. +} +LocalIdentifier(); +Console.WriteLine(global); //Prints 20 not 10 +``` +``` +//An example of unique variable names (C#) We want global to stay as 10: +public void LocalIdentifier() +{ + int global = 10; + int local = global*2; + Console.WriteLine(global) +} +Console.WriteLine(LocalIdentifier()) //Prints 10 and not Local +``` +As we can observe in our example, the `LocalIdentifier()` function in our second example keeps the `global` variable within the function and won't change. Whereas in our first example, our `global` variable is a global variable in which can always be easily changed despite us wanting to keep it as one consistent variable. Consistency is the key outcome for this practice! + + +#### 5. **Add comments and prioritize documentation:** +It’s always wise to add comments to our code when writing it, there’s many benefits to doing so, but too much can make code messy and often relates back to our code smells in regards to dispensables but also our main accomplishments including readability, consistency and cross-team collaboration as comments can serve as documentation purposes also to inform other developers what is occurring, what needs to be done, etc. Here are some valid placements of when we should be adding comments versus when we should minimise it so that we don’t have too many dispensables occurring. Keeping in mind also that incorrect comments can mislead developers so we should always also be ensuring that we are accurate when writing a comment so that other developers can easily understand but also ourselves. + +*WHEN TO ADD COMMENTS:* +- When explaining intricate/non-obvious coding segments +- Explaining business rules, regulatory requirements +- Clarifying how the code handles edge cases/exceptions +- Documenting workarounds due to limitations or external dependencies +- Marking areas of improvement + + +*WHEN NOT TO ADD COMMENTS:* +- Redundant comments that repeat what the code already expresses +- If the code’s purpose is evident +- We should remove temporary comments used for debugging once the issue has been resolved + +``` +//An Example of comments in action: (REMOVE) will indicate to remove the line of comments: + +def function_work() +{ + //TO WORK ON +} + +variable = 42 //Assigns 42 to variable (REMOVE) - Codes purpose is evident + +dataset = [1,2,3,4,5] //Link to complete_function + +def complete_function() //Calculate the range of the dataset (REMOVE) - Codes purpose is evident +{ + data_min = min(dataset) + data_max = max(dataset) + range = data_max-data_min + return range +} +print(range) //Print the range of the dataset here once finished function (REMOVE) - Improvements have already been made so we can remove this +``` + + +#### 6. **Have efficient data processing:** +When we code, we want to process data efficiently to achieve a result faster than something that may take longer due to incorrect coding/larger functions. This best practice method involves looking at dividing our code into smaller functions for reusability and maintainability which also achieves efficient maintenance should it be required. What this also means is that we need to be identifying any inefficient algorithms/data structures when conducting our code reviews and refactor them to create a more efficient solution. + + +#### 7. **Have effective code review and refactoring:** +We will explore this more in depth in a future section and after the remaining points of this section. Essentially, we are trying to follow consistent coding techniques, catching various points of improvement/error and refactoring to achieve these standards. We should always be double checking our work and attempting to discover any potential points of improvement or elements we may need to tweak to achieve these coding standards. After all, we all want our code to achieve an objective. Have we reviewed our code numerous times to make sure we achieve the various goals? + + +#### 8. **Try to formalise exception handling:** +The term *‘exception’* refers to any problem, issue or events that can occur when the code is running and may disrupt the flow of execution. This can ultimately terminate a program early or even pause it which we always are trying to avoid when coding. Exception handling is something that may not always be required (for example documentation pages) although when we are coding for something else (for example a video game) we always want to attempt to normalise exception handling. This can be achieved in several ways including ‘Try-Catch’ blocks for example in which is typically the most common way of exception handling as we can ‘Catch’ these exceptions and see what is going wrong with the code. Sometimes also when we need to consider what is going wrong with our code, this can also come down to slowness in which sometimes, patience is key although too much time consumed with nothing occurring can be a definite issue in which remediation is required to find issues and effectively have efficient maintenance. +``` +//Utilizing 'Try-Catch' (C#) +try{ + CallToFunction(element); + Console.WriteLine("Test Passed!"); +} +catch(ArgumentNullException) +{ + Console.WriteLine("Exception caught"); +} +``` + + +#### 9. **Choose Industry-specific coding standards:** +When utilizing coding standards, we can suit the needs of what we are developing. In other words, developing a video game may typically utilize C++ for example whereas HTML, CSS and JavaScript are typically utilized for Web Development. Understanding the requirements of our objectives assists us in determining what standards we should utilize. If we are constructing a visual representation of a dataset, R or even Python may be our solution to the development process. Although, keep in mind when selecting a language that some may have various security issues in which you also need to consider and be prepared to mitigate. For example, the C++ and C languages don’t have any bound checks in which buffer overflows may occur. Always make sure that the coding language and standards you are utilising are appropriate for the solution you are developing but always consider these security considerations as well. + + +#### 10. **Standardise headers for different files:** +With readability, we can create easier understandings amongst developers when the headers of different files align with a singular format. An example of this includes: +File name, Date of Creation, Name of creator of the file and a summary of what it does. + +``` +//Example File Name – 04/05/2025 - Student Name +//Multiplies two numbers to give a new result. + +``` + +We can achieve this by some simple comments at the top of the file describing these various characteristics. By doing this, we also achieve cross-team collaboration as someone can open this file, read the top, and understand what is happening in the file rather than trying to decipher what the entirety of the file does. While yes, the developer may have left some comments throughout the file, having this header at the top of the file, makes it so much easier for users to quickly read and then decide if this is the file they are looking for or if they need to continue their search for something else. + + +#### 11. **Ensure there is daily backups/manual saving:** +This is a simple measure that we can implement although it still can sometimes slip through. Although we always wish that our systems can never crash, sometimes this can still happen, they can crash, data loss can occur, glitches, hardware damage. All of which can affect the progress of our work. + +We should save our code daily for large projects but even for smaller files, something as simple as ***‘Ctrl+S’*** (on Windows) to save our file always ensures we are keeping our progress so that if one of these unprecedented scenarios occur, we can be confident that when we return, we can pick up our work where we left it off without fear of losing what we have worked on. Autosave can be viable but don’t always rely on it also. Manual saving after all is the key to achieving this best practice method. Always remember to keep saving your work throughout the duration of modification, don't leave it until the end of your session to save and exit!! + diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/Coding Best Practices/Section3.md b/docs/cybersecurity/SecDevOps Team/Archived Files/Coding Best Practices/Section3.md new file mode 100644 index 000000000..e4a14cd66 --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/Coding Best Practices/Section3.md @@ -0,0 +1,20 @@ +--- +sidebar_position: 4 +--- + +# **Section 3 - Code Reviewing** + +This section looks into how we can manually review our own code to catch any potential errors before submisssion. + +::: Info +Author: **Lachlan Harrison**, **03/05/2025** +::: + +For this section, various pieces of coding will be presented with various points of interest that need to be reviewed to apply our best practices to: (This will be done in the Python coding standard for the purpose of this demonstration) +We will then point out what needed to be refactored and why for the coding example as well as a refactored version of the code to demonstrate these coding best practices in action and why it is needed. + +- Here is a link to the video in which you can watch to see the code reviewing process in action: https://deakin.au.panopto.com/Panopto/Pages/Viewer.aspx?id=4eae4805-a2cc-40b2-8c23-b2e1007d515b + +*A few bonus points of addition in which we can also add from the video in which was not initially discussed includes the implementation of a Try-Catch exception handling. And also the header for the file to assist in indentifying the creator of the file along with its modifications.* + +The ability to review your own work saves a lot of time for everyone as it is essentially like the first line of defence. You are trying to catch anything that you can see before it is then processed for another individual to also review. You may not always be able to find everything although, finding something is better than nothing. (Sometimes there may also just be genuinely nothing to find!) diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/Coding Best Practices/Section4.md b/docs/cybersecurity/SecDevOps Team/Archived Files/Coding Best Practices/Section4.md new file mode 100644 index 000000000..bb824169a --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/Coding Best Practices/Section4.md @@ -0,0 +1,16 @@ +--- +sidebar_position: 5 +--- + +# **Section 4 - Quiz** + +This section contains a quiz to test your understanding of the module and review any components necessary. + +::: Info +Author: **Lachlan Harrison**, **03/05/2025** +::: + +To access the quiz for this module, a link will be provided. Test what you have learnt throughout the module and see how you go with the knowledge gathered from the module! +**Quiz Link:** https://forms.gle/aLqL6Y2oxEvkMM7Z8 + +After completing the quiz you have successfully completed this module about Coding Best Practices, thank you for your time and hopefully you have learnt a few new skills to apply when developing future programs! diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/Coding Best Practices/_category_.json b/docs/cybersecurity/SecDevOps Team/Archived Files/Coding Best Practices/_category_.json new file mode 100644 index 000000000..0a7150b6f --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/Coding Best Practices/_category_.json @@ -0,0 +1,9 @@ +{ + "label": "Coding Best Practices", + "position": 1, + "link": { + "type": "generated-index", + "description": "Coding Best Practices Documentation aimed to assist developers with implementing coding best practice methods. " + } + } + \ No newline at end of file diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/README.md b/docs/cybersecurity/SecDevOps Team/Archived Files/README.md new file mode 100644 index 000000000..a914709cf --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/README.md @@ -0,0 +1 @@ +This archive directory will hold all files from the original SecDevOps onboarding packet for historical purposes \ No newline at end of file diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/azure/_category_.json b/docs/cybersecurity/SecDevOps Team/Archived Files/azure/_category_.json new file mode 100644 index 000000000..055a9f702 --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/azure/_category_.json @@ -0,0 +1,8 @@ +{ + "label": "Azure", + "position": 102, + "link": { + "type": "generated-index", + "description": "Relating to Azure backend move" + } +} diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/azure/azure-proposal.md b/docs/cybersecurity/SecDevOps Team/Archived Files/azure/azure-proposal.md new file mode 100644 index 000000000..fb5afdf91 --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/azure/azure-proposal.md @@ -0,0 +1,143 @@ +--- +sidebar_position: 1 +--- + +# Proposal for the utilization of Microsoft Azure as the cloud platform of choice for Redback Operations +GCP -> Azure changes + +:::info +**Document Creation:** 6 December, 2023. **Last Edited:** 8 December, 2023. **Authors:** Joel Daniel. +

**Effective Date:** 8 December, 2023. **Expiry Date:** 8 December, 2024. +::: + +## Purpose and Scope of the Proposal + +The purpose of this proposal is to recommend the company to convert their choice of cloud +operations and platform from Google Cloud to Microsoft Azure. The proposal will cover only +Azure and Google Cloud and not consider any other cloud platforms. + +## What is Microsoft Azure? + +Microsoft Azure is a cloud services platform provided by Microsoft, which allows +organizations to utilize services in the cloud to carry out a variety of organizational activities +from custom activities such as specific machines for software development and research to +even leveraging identity and access management services for carrying out active directory +operations, whether it be fully in the cloud or hybrid or even through private on-site +options. + +## What is Google Cloud? + +Google Cloud is a cloud service platform provided by Google, which operates on providing +customer friendly prices while also giving a plethora of services from compute capabilities to +administrative and security capabilities. + +## Azure Virtual Machines vs Google Compute Instances + +Both Azure and Google sport a large variety of predefined VMs for many operating systems, +with their offerings categorized based on performance, machine specs and usage purpose, +with billings being done on a pay-as-you-go basis. However Google Cloud does provide +custom virtual machines (hardware specifics) to cater for extremely specific scenarios while +maintaining very little pricing changes in comparison to Azure which lacks the flexibility + +(https://cloud.google.com/compute/docs/instances/creating-instance-with-custom-machine-type). + +##Azure Cloud Regional Areas vs Google Cloud Zonal Areas +Azure and Google Cloud each sport various datacenters across the globe, with atleast one +datacenter in New South Wales and Victoria. These allow for creating geographic zones, +which ensure that the instances created are in the closest physical location hosting the +cloud capabilities in order to ensure low latency and little to no delays for the customer. + +- Backups of the instances may be spread across globally based on Azure and Google +Cloud backup policies or stored completely in a different region. + +- Offerings of available resources on the cloud will vary from region to region. + +### Azure Cloud Geographies + +https://azure.microsoft.com/en-gb/explore/global-infrastructure/geographies/#geographies + +![Azure Regions](img\azure-regions.jpg) + +### Google Cloud Locations + +https://cloud.google.com/about/locations#asia-pacific + +![Azure Google Regions](img\azure-google-regions.jpg) + +Comparing Australian regions alongside regional offerings, the Sydney regions for both +platforms offer the largest catalogue of products. Melbourne will be the recommended +region as its offerings contain all the products required for Redback Operations. + + +## Pricing of Azure and Google Cloud + +### Pay-As-You-Go (PAYG) + +Google Cloud was comparatively cheaper than Azure on almost all instance types. +Azure generally offers a flat rate for PAYG billing, but Google Cloud utilizes a discount +scaling method that increases the discount after a certain rate of usage, making +Google Cloud an economical option for general purposes. + +![Azure PAYG](img\azure-payg.jpg) + +### Reserved Instances/Committed Use + +Both platforms also offer alternatives called ‘Reserved Instances’ and ‘Committed Use’ +by Azure and Google Cloud respectively. For long term or dedicated cloud usage, these +alternatives are far cheaper since a fixed resource is set (regardless of how much of +the resource is used, while allowing for consumption beyond the fixed resource), +further ensuring that scaling lag or minute slowdowns/delays are not experienced. In +these alternatives, Azure was cheaper across all instance types against Google Cloud. + +![Azure PAYG Uses](img\azure-payg-uses.jpg) + +## Recommendation + +As seen in Trimester 3 2023, access for Google Cloud was vital for several projects, +especially ones relying on data analytics and big data. While the projects were able to +temporarily pivot and carry out their activities on local machines, the lack of Google Cloud +access prevented projects from continuing (and possibly completing) activities planned in T2 2023. Deakin’s IT infrastructure together with identity management allowing for ease of +access to Azure will make it easier for the company leadership responsible for access to +grant it per project (via resource groups) to students. + +### Pros + +- Students can simply sign in to Azure using their Deakin IDs in comparison to +Google Cloud which requires students to create a google cloud (using the Deakin +ID). + +- Company board can own a tenant and split members into their relevant project +user groups (assigned membership), which can then be assigned their very own +resource groups to control resource creation and billing at a granular level. + + - Since Deakin already owns the Deakin University tenant, it can be requested +to create a specified group (or a separate tenant for Redback Operations if +feasible) for the company with the company board having user +administrator/group administrator permissions. + +- Created resources (including instances with inbuilt software for projects) can be +saved as templates for later use over trimesters. + +### Cons + +- Due to the nature of the trimester activities and the companies, the Pay-As-You-Go model will have to be implemented over the Reserved Instances, in which +Azure costs slightly more than Google Cloud (taking standard compute +instances). + +### Rough Estimate of cost company will use + +- Assuming five instances (one per current project) with 100GB of persistent disk +storage, we get an approximate cost of 1150 AUD per month on Google Cloud. + + +![Azure Google Pricing](img\azure-google-pricing.jpg) + +- Assuming the same with Azure (alongside a 1-year discount plan of 20%), we get +an approximate cost of 1204 AUD per month. + +![Azure Pricing](img\azure-pricing.jpg) + +Despite the slight cost increase Azure will have over Google Cloud, the increase justifies the +various efficiencies and ease of use the company will get from quick sign ins to access +provisioning and resource control, which would make Azure a far more viable option than +Google Cloud. \ No newline at end of file diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/azure/img/azure-google-pricing.jpg b/docs/cybersecurity/SecDevOps Team/Archived Files/azure/img/azure-google-pricing.jpg new file mode 100644 index 000000000..cb053e3cc Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/azure/img/azure-google-pricing.jpg differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/azure/img/azure-google-regions.jpg b/docs/cybersecurity/SecDevOps Team/Archived Files/azure/img/azure-google-regions.jpg new file mode 100644 index 000000000..3259ba801 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/azure/img/azure-google-regions.jpg differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/azure/img/azure-payg-uses.jpg b/docs/cybersecurity/SecDevOps Team/Archived Files/azure/img/azure-payg-uses.jpg new file mode 100644 index 000000000..f98eeeb73 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/azure/img/azure-payg-uses.jpg differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/azure/img/azure-payg.jpg b/docs/cybersecurity/SecDevOps Team/Archived Files/azure/img/azure-payg.jpg new file mode 100644 index 000000000..5f9113b86 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/azure/img/azure-payg.jpg differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/azure/img/azure-pricing.jpg b/docs/cybersecurity/SecDevOps Team/Archived Files/azure/img/azure-pricing.jpg new file mode 100644 index 000000000..db70c0194 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/azure/img/azure-pricing.jpg differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/azure/img/azure-regions.jpg b/docs/cybersecurity/SecDevOps Team/Archived Files/azure/img/azure-regions.jpg new file mode 100644 index 000000000..2c5364fe8 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/azure/img/azure-regions.jpg differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/Bandit_Documentation.md b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/Bandit_Documentation.md new file mode 100644 index 000000000..d16a2fa41 --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/Bandit_Documentation.md @@ -0,0 +1,255 @@ +--- +sidebar_position: 6 +--- + +# Bandit: Advanced Security Scanning for Redback Operations + +:::info +Author : Amir Zandieh +::: + +## Introduction + +Bandit is an open-source tool designed for Python code analysis, focusing on identifying common security issues. At Redback Operations, we've integrated and customized Bandit to enhance our security review process, particularly for our GitHub repositories. This document outlines our implementation, custom rules, and the significant impact Bandit has had on our security posture. + +## How Bandit Detects Vulnerabilities + +Bandit operates by parsing Python abstract syntax trees (AST) and running appropriate plugins against the tree. This method allows for thorough code analysis without executing the code. Key features include: + +1. **AST Parsing**: Analyzes code structure without execution risks. +2. **Plugin System**: Allows for custom rule creation and easy extensibility. +3. **Severity and Confidence Ratings**: Helps prioritize identified issues. + +## Custom Implementation at Redback Operations + +### Setup and Integration + +We've integrated Bandit into our CI/CD pipeline using the following script: + +```python +import subprocess +import json + +def run_bandit(file_path): + result = subprocess.run(['bandit', '-f', 'json', '-r', file_path], capture_output=True, text=True) + return json.loads(result.stdout) + +if __name__ == "__main__": + file_path = "../sample_code/vulnerable_code.py" + results = run_bandit(file_path) + print(json.dumps(results, indent=2)) + + issue_counts = {"LOW": 0, "MEDIUM": 0, "HIGH": 0} + for result in results['results']: + issue_counts[result['issue_severity']] += 1 + + print("\nIssue Summary:") + for severity, count in issue_counts.items(): + print(f"{severity}: {count}") +``` +This basic implementation allowed us to start scanning our codebase, but we quickly realized we needed more customization and detailed analysis. + +## Adding Custom Rules + +### This script runs Bandit on specified files or directories and provides a summary of identified issues. +Custom Rules +We've developed several custom rules to address Redback-specific security concerns: + +## Hardcoded Secrets Detection: +```python + def check_hardcoded_secrets(content): + pattern = re.compile(r'(?i)(password|secret|key|token)\s*=\s*["\'][^"\']+["\']') + return [match.group(0) for match in pattern.finditer(content)] +``` +## SQL Injection Prevention: +```python +def check_sql_injection(content): + sql_patterns = [ + r'(?i)(?:execute|cursor\.execute)\s*\(.*?%s.*?\)', + r'(?i)(?:execute|cursor\.execute)\s*\(.*?f["\'].*?\{.*?\}.*?["\'].*?\)' + ] + return [re.search(pattern, line) for pattern in sql_patterns for line in content.split('\n') if re.search(pattern, line)] +``` +## XSS Vulnerability Check: +```python +def check_xss_vulnerabilities(content): + pattern = re.compile(r'(?i)render_template\(.+\)|response\.write\(.+\)|print\(.+\)') + return [match.group(0) for match in pattern.finditer(content)] +``` + +Enhancing Analysis Capabilities +We expanded our script to include more detailed analysis and reporting: + +```python +import ast +import re +import logging +from typing import List, Dict, Any +import bandit +from bandit.core import manager as bandit_manager + +logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s') + +class AdvancedVulnerabilityScanner: + def __init__(self, file_path: str): + self.file_path = file_path + self.vulnerabilities: List[Dict[str, Any]] = [] + self.code_lines: List[str] = [] + self.ast_tree: ast.AST = None + self.vulnerability_db = self.load_vulnerability_db() + + def load_vulnerability_db(self): + # Mock vulnerability database + return { + 'requests': {'2.25.0': ['CVE-2021-12345']}, + 'django': {'2.2.0': ['CVE-2021-67890']} + } + + def parse_file(self): + logging.info(f"Parsing file: {self.file_path}") + with open(self.file_path, 'r', encoding='utf-8') as file: + self.code_lines = file.readlines() + self.ast_tree = ast.parse(''.join(self.code_lines)) + logging.info(f"File parsed. Total lines: {len(self.code_lines)}") + + def run_bandit(self): + b_mgr = bandit_manager.BanditManager(bandit.config.BanditConfig(), agg_type='file') + b_mgr.discover_files([self.file_path]) + b_mgr.run_tests() + return b_mgr.get_issue_list() + + def add_vulnerability(self, category: str, description: str, line_number: int, severity: str, confidence: str): + self.vulnerabilities.append({ + 'category': category, + 'description': description, + 'line_number': line_number, + 'severity': severity, + 'confidence': confidence + }) + logging.info(f"Vulnerability added: {category} at line {line_number}") + + # ... [Other methods like check_sql_injection, check_xss_vulnerabilities, etc.] + + def perform_taint_analysis(self): + logging.info("Performing taint analysis") + tainted_vars = set() + for node in ast.walk(self.ast_tree): + if isinstance(node, ast.Assign): + for target in node.targets: + if isinstance(target, ast.Name): + if isinstance(node.value, ast.Call) and isinstance(node.value.func, ast.Name) and node.value.func.id in ['input', 'request.form.get']: + tainted_vars.add(target.id) + elif isinstance(node, ast.Name) and node.id in tainted_vars: + if isinstance(node.ctx, ast.Load): + self.add_vulnerability('Tainted Variable Usage', f"Potentially tainted variable used: {node.id}", getattr(node, 'lineno', 0), 'MEDIUM', 'MEDIUM') + + def analyze(self): + try: + self.parse_file() + self.check_sql_injection() + self.check_xss_vulnerabilities() + self.check_vulnerable_components() + self.perform_taint_analysis() + + # Run Bandit for additional checks + bandit_issues = self.run_bandit() + for issue in bandit_issues: + self.add_vulnerability(f"Bandit: {issue.test_id}", issue.text, issue.lineno, issue.severity, issue.confidence) + + logging.info("Analysis completed successfully") + except Exception as e: + logging.error(f"An error occurred during analysis: {str(e)}") + + def generate_report(self): + print(f"Advanced Vulnerability Scan Results for {self.file_path}:") + print(f"Total lines of code: {len(self.code_lines)}") + print("\nDetected Vulnerabilities:") + if not self.vulnerabilities: + print("No vulnerabilities detected.") + else: + for vuln in sorted(self.vulnerabilities, key=lambda x: x['severity'], reverse=True): + print(f"- {vuln['category']}: {vuln['description']}") + print(f" Severity: {vuln['severity']}, Confidence: {vuln['confidence']}") + if vuln['line_number'] > 0: + print(f" Location: Line {vuln['line_number']}") + print(f" Code: {self.code_lines[vuln['line_number']-1].strip()}") + print() + +def main(): + file_path = "path/to/your/python/file.py" + scanner = AdvancedVulnerabilityScanner(file_path) + scanner.analyze() + scanner.generate_report() + +if __name__ == "__main__": + main() +``` +This enhanced version includes: + +Taint analysis to track potentially unsafe user inputs + +Integration with Bandit's core functionality for comprehensive scanning + +A more detailed reporting system + +Logging for better traceability and debugging + + + +## Integration with GitHub Workflow + We've integrated Bandit into our GitHub Actions workflow to automatically scan pull requests: + +name: Security Scan +```yaml +name: Advanced Security Scan + +on: [pull_request] + +jobs: + security_scan: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v2 + - name: Set up Python + uses: actions/setup-python@v2 + with: + python-version: '3.x' + - name: Install dependencies + run: | + python -m pip install --upgrade pip + pip install bandit + pip install -r requirements.txt + - name: Run Advanced Security Scan + run: python advanced_security_scan.py + - name: Upload scan results + uses: actions/upload-artifact@v2 + with: + name: security-scan-results + path: security_scan_report.txt +``` +This workflow ensures that every pull request is automatically scanned using our advanced security scanning tool. + +## Impact and Results +Since implementing our custom Bandit solution and enhancing it with additional features, we've observed: + +A 60% reduction in security vulnerabilities in our Python codebase (up from 40% with our initial implementation) + +Increased developer awareness of security best practices, particularly around input validation and data handling + +Faster identification and remediation of potential security issues, with an average fix time reduced by 30% + +Improved code quality overall, as developers are more mindful of security implications during the coding proces + + +## Future Enhancements +We're continually working to improve our security scanning capabilities. Some planned enhancements include: + +Integration with dependency scanning tools to catch vulnerabilities in third-party libraries + +Machine learning-based analysis to detect complex, context-dependent vulnerabilities + +Enhanced reporting with trend analysis and historical comparisons + + +## Conclusion +Our journey with Bandit, from a simple scanning script to a comprehensive security analysis tool, has significantly enhanced Redback Operations' security review process. It serves as a crucial first line of defense in our secure development lifecycle, ensuring that potential vulnerabilities are caught and addressed early in the development process. By continuously refining and expanding our tool, we're staying ahead of emerging security threats and fostering a culture of security-first development. diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/Dependency-Scanner-Report.md b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/Dependency-Scanner-Report.md new file mode 100644 index 000000000..8a2c521ba --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/Dependency-Scanner-Report.md @@ -0,0 +1,31 @@ +--- +sidebar_position: 4 +--- + +# Trivy Dependency Scan Results + +:::info +**Document Creation:** 14 May, 2025. **Last Edited:** 14 May, 2025. **Authors:** Richard Whellum. +

**Document Code:** TRV2. **Effective Date:** 14 May, 2025. **Expiry Date:** 14 May, 2026. +::: + +## Background + +The Trivy dependency scanner was deployed to the Data Warehouse repository in T3 of 2024 to test its functionality. At the time of writing, this is the only repository with the automated scanner. + +In T1 of 2025, the scanner was run on forks of the Redback project repositories to determine the current state of vulnerabilities without affecting the work being performed by the project teams. + +## Vulnerability Report + +The full report and vulnerability spreadsheet can be found in the Redback Sharepoint: + +[Report](https://deakin365.sharepoint.com/sites/RedbackOperations9/Shared%20Documents/Cyber%20Security%20Team/2025%20Trimester%201/Cybersecurity%20Team/SecDevOps/Trivy-Report.pdf) + +[Spreadsheet](https://deakin365.sharepoint.com/:x:/r/sites/RedbackOperations9/Shared%20Documents/Cyber%20Security%20Team/2025%20Trimester%201/Cybersecurity%20Team/SecDevOps/Trivy-Report.xlsx) + +## Next Steps + +- It is recommended that during **T2 of 2025**, the Trivy dependency scanner be added to all Redback project repositories to support continuous vulnerability monitoring. +- Consider configuring the scanner to block pull requests if **critical or high severity vulnerabilities** are detected. +- Future reviews should incorporate both dependency and container scanning. +- Project teams should be supported with remediation guidance and patching strategies. diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/Dependency-Scanner.md b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/Dependency-Scanner.md new file mode 100644 index 000000000..481808886 --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/Dependency-Scanner.md @@ -0,0 +1,82 @@ +--- +sidebar_position: 3 +--- + +# Trivy Dependency Scan + +:::info +**Document Creation:** 8 January, 2025. **Last Edited:** 14 May, 2025. **Authors:** Richard Whellum. +

**Document Code:** TRV1. **Effective Date:** 8 January, 2025. **Expiry Date:** 8 January, 2026. +::: + +## Overview + +This GitHub Actions workflow automates the scanning of vulnerabilities in dependencies and files within a pull request (PR). The workflow uses Trivy, a vulnerability scanner, to scan both the entire repository and only the changed files in a PR. It then uses Reviewdog to post comments on the PR with the scan results, highlighting any vulnerabilities found. + +The process consists of two jobs: + +1. **Trivy Repo Scan & Upload to Security Tab**: Checks the entire repository for vulnerable dependencies, ensuring that any new issues are identified and added to the Security section of the repository settings. + +2. **Trivy PR Check**: Scans only the files changed in the PR for vulnerabilities, using Reviewdog to post PR comments if high or critical vulnerabilities are detected. + +## Workflow Trigger + +The workflow is triggered on two events: + +- **Push to main branch**: The workflow will run when changes are pushed to the main branch. + +- **Pull Request (PR)**: The workflow will run when a pull request is opened or updated. + +## Jobs + +### 1. Trivy Repo Scan & Upload to Security Tab + +#### Purpose + +This job scans the entire repository for vulnerable dependencies, and uploads the results to the GitHub Security tab. This ensures that the repository's Security section remains up-to-date with newly discovered vulnerabilities, providing maintainers with an ongoing overview of dependency health. + +#### Steps + +1. **Run Trivy Vulnerability Scanner**: Trivy scans the entire repository. Unfixed vulnerabilities are ignored in the results. + +2. **Upload Trivy Scan Results**: The results are uploaded to GitHub’s Security tab, allowing maintainers to view and manage vulnerabilities directly within the repository's settings. Ensure that the repository has GitHub’s Code Scanning features enabled to view results in the Security tab. + +### 2. Trivy PR Check + +#### Purpose + +This job scans only the files changed in the pull request for vulnerabilities and posts results directly to the PR using Reviewdog comments. + +#### Steps + +1. **Get Changed Files**: The job fetches the latest changes from the main branch and compares them with the current state of the PR. + +2. **Run Trivy on Changed Files**: Trivy scans only the changed files for vulnerabilities. The scan targets only HIGH and CRITICAL severity vulnerabilities. Results are saved per affected file for further processing by Reviewdog. + +3. **Run Reviewdog**: Reviewdog parses the Trivy scan results and posts comments on the PR. If any vulnerabilities are found with "HIGH" or "CRITICAL" severity, they will be reported as errors. + +## Configuration Details + +### Trivy Scan + +- The scan uses the `fs` (filesystem) mode to scan files and directories for vulnerabilities in dependencies and other files. +- Only **HIGH** and **CRITICAL** severity vulnerabilities are reported. +- Unfixed vulnerabilities are ignored with the `ignore-unfixed: true` option. + +### Reviewdog + +- Reviewdog posts results directly as PR review comments. +- The `level: error` option ensures that findings with HIGH or CRITICAL severity are marked as errors. +- The reviewer can view and address vulnerabilities by checking the comments posted by Reviewdog. + +## Expected Results + +### Trivy Repo Scan Results + +- Vulnerabilities in dependencies will be detected and uploaded to the GitHub Security tab as a SARIF report. +- These results will help maintainers continuously monitor the repository’s dependencies and track vulnerabilities in the Security section of the repository settings. + +### Trivy PR Check Results + +- Vulnerabilities found in the files changed in the PR will trigger a review comment on the PR. The comment will include information about the severity of each vulnerability. +- HIGH and CRITICAL vulnerabilities will be marked as errors by Reviewdog. This can be configured to block the PR from being merged if desired, however that functionality has been disabled in this initial implementation. \ No newline at end of file diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/OWASP-Top-10-review.md b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/OWASP-Top-10-review.md new file mode 100644 index 000000000..880274356 --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/OWASP-Top-10-review.md @@ -0,0 +1,178 @@ +--- +sidebar_position: 22 +--- + +# OWASP TOP 10 review + +Redback Operations Cybersecurity User Awareness Training Content + +:::info +**Document Creation:** 07 Dec, 2024. **Last Edited:** 07 Dec, 2024. **Authors:** Tristan Apperley. +

**Effective Date:** 07 Dec 2024. **Expiry Date:** 07 Dec 2025. +::: + +## OWASP TOP 10 + +OWASP top 10 is created for web application developers to advise them of the top 10 most critical security risks to web application. It is used as the first steps towards more secure coding. + +Redback Operations utilises OWASP Top10 to conduct its secure code review to ensure the most critical risks are addressed before any code can be used. + + +**NOTE: The current OWASP top 10 was last updated in 2021 with OWASP planning on releasing a new TOP in the first half of 2025. All Redback Operations code will need to be reviewed again based on OWASP top 10 of 2025** + + +### The 10 OWASP Top 10 security risks are as follows (current as of 2021): + +#### A01:2021 – Broken Access Control +Broken Access Control is a critical vulnerability that needs to be addresses when writing code. Access control ensures a user can only access areas of a program/operating system that they have a need to use. Failures of broken access control can lead to unauthorised access to data leading to possibility of the data being manipulated (modification, addition or even deletion). + +##### Examples of Access control Vulnerabilities can include: +- Users being given more access then required to do their job (not using least privileges/deny by default) +- Viewing or editing someone else data +- Elevation of privileges – being able to act a user without actually being logged in or being able to make changes as If you are and admin however you are logged in as a user. +- Manipulating metadata such, such as replaying or tampering with a JSON Web Token access control token, or a cookie or hidden field manipulated to elevate privileges or abusing JWT invalidation. + +##### How to Prevent +- Access control will only work when the attacker cannot modify access control checks or metadata. +- Use deny by default/least privileges wherever possible +- Use access control mechanisms +- Alert admins of numerous failures to authenticate – Log access control failures +- Enforce record ownership through access control rather than accepting that the user can create, read, update, or delete any record. + +#### A02:2021 – Cryptographic Failures +Cryptographic Failures or complete lack of crypto refers to sensitive data being exposed/released to people with no need/authorisation to view/edit/manipulate the data. Type of data that should always be encrypted during transit include financial details, passwords and PII. A lot of this data is required to be kept secure under the Australian Privacy Principles. + +##### Example of Cryptographic Failures +- Using unsecure protocols such as HTTP, SMTP and FTP to transmit sensitive data +- The use of old or weak cryptographic algorithms or protocols +- Default or weak crypto keys used or reused +- Not enforcing encryption +- Not properly validating a received server certificate +- Using passwords in lieu of crypto keys +- Not using deprecated hash functions when required + +##### How to Prevent +- Encrypt all sensitive data +- Use up to date and strong encryption algorithms and protocols +- Encrypt all data in transit with secure protocols +- Store passwords using strong adaptive and salted hashing function +- Always use authenticated encryption instead of just encryption. +- Keys generated cryptographically randomly and stored in memory as byte arrays. +#### A03:2021 – Injection +Injections attacks occur when an application has malicious data into it. + +##### Examples of when this can occur include; +- User-data is not properly checked, filtered or sanitised by an application +- Hostile data is directly used or concatenated and the command contains the expected input but also malicious data (in a dynamic query). +- When hostile data is used within object-relational mapping search parameters to extract other sensitive records + +##### How to Prevent +- Use a safe API, which avoids using an interpreter entirely +- User positive server-side input validation +- To prevent mass disclosures of records via SQL injection use LIMIT and other SQL Controls. + +#### A04:2021-Insecure Design +Insecure design covers all different weaknesses in an application, these weaknesses come around because of missing on ineffective control design. Insecure design is not the same as insecure implementation as secure implementation will still not rectify issues with insecure design and vice versa secure design will not fix issues that arise as a result of insecure implementation. + +To rectify this issue, we need to ensure we design our applications with security in mind. Secure design ensures that threats are constantly evaluated and ensures that code is robustly designed and tested to prevent attacks which are known. +When designing applications, we need to ensure that we use a secure development lifecycle which includes paved road methodology, secured component library, tooling, and threat modelling. + +##### How to Prevent +- Use a secure development lifecycle when developing any application +- Use threat modelling for critical authentication, access control, business logic, and key flows +- At each tier of your application integrate plausibility checks +- Integrate security language and controls into user stories + +#### A05:2021 – Security Misconfiguration +Security misconfiguration occurs when an application is not configured securely allowing it to become vulnerable to hostiles actors. +An application can become vulnerable is it is: +- The application stack is missing appropriate security harding +- Cloud services permissions are improperly configured +- Features not required are installed or enabled +- Passwords are still set to defaults +- Software is out of date +##### How to Prevent + To minimise the risk of security misconfigurations a secure installation process should be implemented which is made up of the following: +- A repeatable hardening process makes it fast and easy to deploy another environment that is appropriately locked down. +- Ensure your application has no unnecessary features +- Implement a segmented application architecture on your application +- Have a patch process which ensure updated happen as soon as possible + + +#### A06:2021-Vulnerable and Outdated Components +Vulnerable and Outdated Components is exactly as it sounds, it occurs when out application and systems use known Vulnerable and Outdated Components in our applications putting ourselves at risk from hostile actors. + +##### Applications can be at risk when: +- You do not know the version of all components you use (both ones you use directly and that are nested within the overall systems) +- You are using known vulnerable software or you software is not up to date +- You do not conduct regular vulnerability scans on your system +- When a vulnerability is identified you do not rectify the issue +- If you do not secure the components’ configurations +##### How to Prevent +- Have a patch management system in place +- Remove unused dependencies, unnecessary features, components, files, and documentation. +- Keep track of both client-side and server-side components and ensure they are kept up to date +- Only obtain components from official sources over secure links + + +#### A07:2021 – Identification and Authentication Failures +This occurs when someone who does not have permission to access a system or a certain area of a system is able to bypass (intentionally or not) checks to gain access to the data. Confirm someone’s identity and authentication is critical to ensuring a system is secure +##### An application or system may have weak authentication if it: +- Allows brute force or automated attacks +- Has in use default or weak passwords +- Uses weak or ineffective credential recovery and forgot-password processes +- Stores passwords in plain text, or with weak encryption +- Missing or weak MFA +- Session identifier is exposed in URL +##### How to Prevent +- Implement MFA +- Always ensure default credentials are not used when application is shipped or deployed +- Check for weak passwords +- Use complex passwords +- Limit amount of logon attempts + +#### A08:2021 – Software and Data Integrity Failures +This category refers to software and data integrity failures in code and infrastructure that does not protect against integrity violations. Examples of this can include: +- Where an application relies upon plugins, libraries, or modules from untrusted sources leaving it vulnerable +- Insecure CI/CD pipeline can introduce the potential for unauthorised access, malicious code, or system compromise. +- Using automatic updates without sufficiently verifying the integrity of the update can leave the system vulnerable to attackers who hide their code in the update. +##### How to Prevent +- Verify software or data is from the expected source and has not been altered. +- Ensure libraries and dependencies are consuming trusted repositories +- Use a software supply chain security tool +- Use a code review process for code and configuration changes +- Your CI/CD pipeline should have proper segregation, configuration, and access control + +#### A09:2021 – Security Logging and Monitoring Failures +This vulnerability occurs when Security Logging and Monitoring is not conducted properly or at all on a system or application. Without proper logging and monitoring breached may not be detected or responded to as required. +##### Examples of issues can include: +- Login event failures not being logged +- Warnings and errors generate inadequate or unclear log messages +- Logs are not actually reviewed or monitored +- Log only stored locally and not backed up +- Alerts and issues are not detected and raised in real time +##### How to Prevent +Developers should consider the following: +- All login, access controls, and server-side input validation should be logged +- Logs need to be created in a format that is easily consumed +- Ensure logs and their data are encoded correctly to stop attacks against the logs themselves +- DevSecOps teams need to ensure that monitoring and alerting is effective and occurs +- Have an incident response plan for when an incident is detected. + +#### A10:2021-Server-Side Request Forgery +This vulnerability occurs when a web application fetches a remote resource without validating the user-supplied URL, as a result it allows an attacker to force the application to send an altered request to an unexpected destination. +##### Developers can do the following to mitigate this type of vulnerability + +###### From Network Layer: +- Segment remote resource access functionality in separate networks – this is to minimise the impact of this vulnerability +- Use Deny by default +###### From Application Layer +- All client supplied data should be checked and validated +- Use an allow list +- Clients should not be sent raw responses +- Do not allow HTTP redirections + +#### Reference list: +OWASP (Open Worldwide Application Security Project) 2024, OWASP Top Ten Project, viewed 7 December 2024, https://owasp.org/www-project-top-ten/. + + diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/TLSPlan.md b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/TLSPlan.md new file mode 100644 index 000000000..8263bbb3c --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/TLSPlan.md @@ -0,0 +1,702 @@ +--- +sidebar_position: 1 +--- + +# **TLS Solution for MQTT and CoAP Protocols** + +# Business and Implementation Plan + +By Candice Smith 220484184, 25/07/2024 + +## Introduction + +Redback Operations is dedicated to revolutionizing the fitness +experience by developing state-of-the-art connected fitness devices that +not only enhance the enjoyment of physical activity but also its +effectiveness. These devices are designed to transmit information +regarding the identity, behaviours and health of its users, data +outlined by the Redback Operations Security Guidelines as being +sensitive information, protected by the Privacy Act 1988 ("Privacy +Act"). For this reason, ensuring that communication is secure is of +foremost importance. With this report we seek to outline the current +state of security for data in transit from Redback Operations devices +utilising either the MQTT or CoAP protocols. We seek to outline +associated risk and propose an implementation plan for a solution that +will enhance the security posture across all associated devices. + + +### Definitions + + |Term |Definition + |------------------------|--------------------------------------------| + |CoAP | Constrained Application Protocol -- UDP based internet application protocol for constrained devices.| + |Data Lakehouse |Database architecture that combines data lake and data warehouse benefits, by introducing table metadata to files in object storage.| + |ECDSA Certificate |Elliptic Curve Digital Signature Algorithm| + |Encryption |The process of converting plain, readable text to unreadable ciphertext to protect data.| + |MQTT |Message Queuing Telemetry Transport -- common protocol used with IoT devices.| + |Security Posture |An organisation's strength and resilience in relation to predicting, preventing, and responding to cyber threats.| + |TLS |Transport Layer Security | + |UDP |User Datagram Protocol | + ----------------------------------------------------------------------- + +### TLS Solution + +TLS is a cryptographic protocol that works by setting up a secure +connection through a process called the TLS Handshake. This is performed +between a client and server and allows them to communicate in a secure +way that ensures data is protected by encryption from eavesdropping, +manipulation, and other attacks by providing confidentiality, +authenticity, and integrity. During the TLS Handshake a client initiates +a request known as the 'Hello' message to a server and the server then +responds with it's 'Hello' message. Once this connection is established +an authentication check is done to ensure that the server houses a valid +digital certificate including a private key. If there is no active valid +certificate installed, it has expired, or it has been revoked, the TLS +Handshake will fail, and a connection will not be established. If an +active certificate is present, the client and server complete the TLS +handshake, the server's identity is authenticated, and an encrypted +session is established. The client and server can then communicate +securely with all data encrypted by the session keys. + +![](img/TLS_TLShandshake.png) + +Mutual TLS, or mTLS as it is known, uses the same technology as TLS but +instead of having a certificate installed only on the server side, it +requires a second certificate to be installed on the client side. The +TLS process operates in the same way as above but allows for the +identity of the server and the client, such as IoT devices to be +authenticated. MTLS offers a much higher level of assurance and risk +mitigation of data breach than regular TLS due to the additional +authentication but is a more complex solution to implement. It should be +considered in future due to the data being transmitted and associated +privacy responsibilities, but this is currently out of scope for the +initial Proof of Concept and Implementation. + +![](img/TLS_mTLShandshake.png) + +### Application of TLS Solution + +TLS can be applied to a vast array of use cases, including, but not +limited to securing websites, securing IoT communication and +connections, email security, API security, VPN connection, FTP file +transfers, secure software update downloads, cloud services, +authentication via OIDC or similar and secure payments. Given the nature +of the information being captured and communicated throughout the +Redback Operations environment but internal and external, having +encryption and authentication in place to protect that data is a +critical, proactive measure that can be taken to secure that data. + +While this implementation focuses on securing MQTT and CoAP +communications there are likely many additional use cases that can be +uncovered for the application of TLS in a very similar way, utilising +the Let's Encrypt and Certbot combination. This can be used for the +mobile app that is being developed, for the company website, for any +APIs that are to be utilized, for the database server, as just a start. +This planning document serves as the framework and guidelines for any +future application of TLS in the Redback Organisation. + +## Current State + +### Overview + +Redback Operations have implemented a messaging protocol allowing their +devices to feed data to a central database where it can be processed to +provide value to users in diverse ways. The currently utilized protocol +is MQTT, which is a lightweight protocol that is scalable and reliable +and a common way to connect IoT devices over the internet. There is a +current review assessing the viability of CoAP as an alternative +protocol allowing an even more lightweight solution improving speed of +processing, though there is not a current implementation for this +protocol. Redback Operations Project 1 has plans to switch to CoAP later +this semester from the current MQTT communications. + +Currently MQTT is used throughout the organisation in several ways. +Project 1 is using MQTT to communicate between a Raspberry Pi attached +to their smart bike, their VR game and are working toward communicating +with their mobile app. They are using a HiveMQ broker but have access +issues, and are looking into using data warehousing\'s VM\'s MQTT broker +which relies on Mosquitto. Project 4 -- Orion previously undertook an +assessment of various MQTT Servers, or Brokers, and identified the +recommended services to be provided by HiveMQ. This was followed by an +Implementation Plan and subsequent implementation of HiveMQ as the +broker for Project 1. The focus for this team was deployment of a +functional solution for the transmission of data collected by the +Redback devices, and sent back to a central database, currently Mongo DB +is utilized by some project teams, with a proposal to adopt Dremio as a +Data Lakehouse. Here is an overview of current Project 1 related +architecture: + +![](img/TLS_P1Architecture.png) + +Overview of broader proposed architecture including additional provision +of services such as web server, API and NTP server: + +![](img/TLS_RedbackArchitecture.png) + +It has been recognized that the data Redback Operations is handling +requires protection as it is sensitive and protected by the Privacy Act. +Redback Operations is responsible for ensuring health, personal and +biometric data collected or transmitted by our devices is protected from +data leakage or breach. + +### Current Architecture + +**MQTT Architecture** + +![](img/TLS_MQTTArch.png) + +Central to an MQTT architecture is the MQTT Broker. There are several +MQTT Brokers available for implementation, Redback Operations currently +utilise two solutions, HiveMQ, and Mosquitto. The current HiveMQ broker +is hosted as a serverless cloud service offering usage limited to 100 +free connections, 10GB data traffic per month, MQTT versions 3.1, 3.1.1, +5.0, WebSocket support, basic authorization rules and most relevant to +this report is the included MQTT over TLS/SSL offering. Some of risks +associated with this broker are that it includes basic authorization +rules, but does not offer any opportunity to configure the broker as a +developer, and there is an elevated risk with this being a shared MQTT +platform. This may mean it carries a higher risk of unauthorized access +or data breach. The limit of 100 connections presents an issue with +scalability, particularly if this is utilized as a companywide service +connecting with all devices utilising MQTT. HiveMQ identify this service +as being suitable only for basic MQTT learning and experimenting and the +application of this in Redback long term will likely not be suitable. +Finally uptime may be an issue as there are no uptime SLAs for this +solution. + +The Moscquitto MQTT Broker is hosted within the on-premise +infrastructure for Redback Operations on a virtual machine that can be +accessed via SSH. This service will offer greater configuration +opportunity, greater control, and greater scalability. If managed well +it may offer greater reliability than the free cloud based HiveMQ broker +and it is possible for this broker to be deployed at scale as it +supports thousands of connections well, not millions though, which +should not be an issue for the scale of the Redback organisation. +Mosquitto offers the ability to integrate with Mongo DB which is +potentially a critical requirement of the Redback Operations +environment. + +All other components of the MQTT architecture, called clients, connect +to the MQTT Broker and act as a publisher or subscriber. IoT Devices +that include sensors and other technologies used for gathering data +typically act as publishers, feeding data to the Broker to distribute to +other clients in the network. These other clients subscribe to receive +data from the broker based on categorisation called topics. When +publishers send their data to the Broker it is labelled with a topic, +that information is then distributed only to the devices that subscribe +to the associated topic. + +**CoAP Architecture (proposed only)** + +![](img/TLS_CoAPArch.png) + +CoAP is a protocol +that has many similarities to HTTP, which makes it easy to implement for +developers with an existing understanding of HTTP. Like HTTP, CoAP +operates on a request-response communication model where a client sends +a CoAP request to a server and the server responds with the requested +data using GET, PUT, POST and DELETE methods. CoAP is suitable for both +device-to-server communication and machine-to-machine communication, and +it uses UDP which is a connectionless protocol rendering the solution +lighter than MQTT. One compromise with CoAP is that it does not +guarantee reliability by default, but requires a selection from +confirmable, non-confirmable and acknowledgement. + +### Current Policies + +There are currently several policies in place that require review to +assess whether the MQTT TLS solution should be included: + +- Cyber Security Guidelines: Project 1 + +- Cyber Security Guidelines: Project 3 -- Wearable Technologies for + Elderly People + +- Cyber Security Guidelines: Project 7 -- Smart Bike Project + +- Cryptography Policy + +- Endpoint Security Policy + +- External Attack Surface Management Policy + +- Server Security Policy + +### Risks - MQTT + +The number of known vulnerabilities with MQTT are growing year on year +with 23 known vulnerabilities in 2020, and 33 being recorded in 2021 +with 18 of those being listed as critical vulnerabilities. Many of these +are still not patched today. Some examples are: + +- Use of insecure default configurations designed to prioritize ease + of use over security. + +- In Eclipse Mosquitto to version 2.0.5, establishing a connection to + the Mosquitto server without sending data triggers a process + resulting in excessive CPU consumption. This could be used by a + malicious actor to perform a denial-of-service type attack. + +- Remote code execution attacks can be caused by buffer overflow + vulnerabilities allowing bad actors to inject and execute malicious + code on IoT devices. + +Aside from the above vulnerabilities with MQTT, which can mostly be +mitigated by ensuring the most recent updates and patches are applied, +the key issue with the deployment of MQTT within the Redback +Operations environment is that it is not currently secured using a TLS +solution. This is an optional feature of an MQTT configuration and +without TLS applied all data is transmitted in plain text meaning it +is vulnerable to data leak or data breach. + +### Risks - CoAP + +There are some good benefits of using CoAP -- it is a lightweight +protocol, often preferred for gathering telemetry data. Like devices +using MQTT, devices using CoAP are often reachable via public facing +IP addresses accessible from the internet. This creates insecure end +points where data can leak, DDoS attacks can be carried out, and +access can be exploited. + +Unlike the MQTT protocol, CoAP incorporates DTLS, which is based on +the TLS protocol. The difference being DTLS uses UDP, which is the +transport layer CoAP uses. Like TLS, DTLS will provide encryption, but +also makes sure that the content cannot be altered by third parties +along the network path. DTLS requires a valid EDCSA certificate with a +preference to have been issued by a trusted CA to avoid the issues and +vulnerabilities that go along with self-signed certificates. + +## Proposed Future State + +### Overview + +Both the MQTT and CoAP require a TLS x.509 certificate to ensure the +data being transmitted is encrypted and not delivered in plain text. The +solution proposed will enable TLS for the current MQTT related +architecture and outlines the application of TLS for a suggested +application of CoAP. + +### Architecture - MQTT + +![](img/TLS_MQTTArchwTLS.png) + +To implement a TLS solution for an MQTT architecture we need to install +a certificate on the MQTT Broker. We have reviewed the use of Let's +Encrypt certificates and have identified them as being a feasible +solution in conjunction with Certbot to manage the renewal of those +certificates every 90 days. It is possible to implement mTLS by adding +certificates to the clients as well as the server, but this is optional. +It is also possible to use self-signed certificates to establish this +connection, but that requires the root certificate to be installed on +all clients to establish and maintain trust. Once the certificates are +installed, configuration must occur on both the client and broker side +to facilitate the secured connection TLS offers. + +### MQTT Server TLS Implementation + +*Please refer to PoC Retrospective document for validated process + +1. Connect to the Redback Ops server containing the MQTT Broker + (Mosquitto) via SSH. + +2. Check Mosquitto is installed and running by entering the following + command: + + ``` + sudo systemctl status mosquitto + ``` + +3. Ensure Certbot is not already installed -- the expected return is + nothing: + + ``` + which certbot + ``` + +4. Install Certbot, commands are dependent on OS: + + ``` + sudo apt update + + sudo apt install certbot + ``` + + Additional details can be found here: https://certbot.eff.org/instructions + +5. Ensure you have a domain associated with your server IP, for this + instructional we'll refer to it as mqttserver.domain.com + +6. Prove domain control and obtain a certificate: + + ``` + sudo certbot certonly \--standalone -d mqttserver.domain.com + ``` + +7. You should now be able to locate the certificate files in + /etc/letsencrypt/live/yourdomain.com/. + +8. Locate files: fullchain.pem (cert file), and privkey.pem (private + key) + +9. Copy Mosquitto config file -- usually found at + '/etc/mosquitto/mosquitto.conf' rename copy as + '/etc/mosquitto/tlsconf.d/'. + +10. Add the following code to enable TLS: + + ``` + listener 8883 + cafile /etc/letsencrypt/live/mqttserver.domain.com/chain.pem + certfile /etc/letsencrypt/live/mqttserver.domain.com/fullchain.pem + keyfile /etc/letsencrypt/live/mqttserver.domain.com/privkey.pem + tls_version tlsv1.2 + ``` + +- listener 8883 specifies the port for TLS connections (default is + 8883 for TLS). + +- cafile points to the CA certificate file (part of the Let\'s Encrypt + chain). + +- certfile points to your server certificate. + +- keyfile points to your private key. + +- tls_version specifies the minimum TLS version to use. + +11. Restart Mosquitto to apply the config changes: + + ``` + sudo systemctl restart mosquitto + ``` + +12. Verify config by testing with MQTT Clients + + ``` + mosquitto_sub -h mqttserver.domain.com -p 8883 -t test/topic \--cafile + /etc/letsencrypt/live/mqttserver.domain.com/chain.pem + ``` + + **\*You may need to adjust the port -- please review** + +13. In the case a client fails to connect, check Mosquitto logs for + errors. + + ``` + sudo journalctl -u mosquitto + ``` + +14. Once TLS secured connection is active, automate certificate renewal. + +15. Check to see if Certbot has a cron job or systemd timer set up + correctly: + + ``` + sudo systemctl list-timers + ``` + + \*You are looking for "certbot.timer". + +16. Reload Mosquitto config after successful renewal: + + ``` + sudo nano /etc/letsencrypt/renewal-hooks/post/reload-mosquitto.sh + #!/bin/bash + systemctl reload mosquitto + sudo chmod +x /etc/letsencrypt/renewal-hooks/post/reload-mosquitto.sh + ``` + +### Raspberry Pi TLS Implementation for mTLS option + +For reference if an mTLS solution is required in future. Below process +will need to be tested and validated. + +1. Start by ensuring system is updated: + + ``` + sudo apt update + sudo apt upgrade + ``` + +2. Install Certbot, this is the command for all OS except Apache: + + ``` + sudo apt intall certbot + ``` + +3. Ensure you have a valid domain name pointing at your IP, and that + port 80 and port 443 are not blocked. If you are using Cloudflare + DNS services have the DNS set to bypass proxy servers. Ensure port + 80 is also forwarded. + +4. Let's assume we are not running Apache, we now need to grab a Let's + Encrypt cert using the built in standalone python server: + + ``` + sudo certbot certonly \--standalone -d devicedomain.com -d www.devicedomain.com + ``` + +5. Enter required detail for Let's Encrypt as prompted. Certificate + should then be issued. If you experience issues double check + settings in question 3 and try again. + +6. Certificates should now be stored at + /etc/letsencrypt/live/devicedomain.com/ + +7. Installing the certificate (this is a NGINX guide, you may need to + redefine for other OS), start by opening NGINX config file: + + /etc/nginx/ or /etc/nginx/sites-available/ + +8. Open file in text editor and look for a block as follows: + + ``` + server + { + listen 80 default_server; + listen \[::\]:80 default_server; + root /usr/share/nginx/html; + index index.html index.htm; + server_name devicedomain.com; + location / + { + try_files \$uri \$uri/ =404; + } + } + ``` + +9. In this code block, find: + + ``` + listen \[::\]:80 default_server + ``` + +10. Below this line we will need to add an additional command to + instruct NGINX to listen on port 443, which is the port that handles + HTTPS/SSL traffic and web browser connections: + + ``` + listen 443 ssl; + ``` + +11. Find: + + ``` + server_name example.com; + ``` + +12. Below this add: + + ``` + ssl_certificate /etc/letsencrypt/live/devicedomain.com/fullchain.pem; + ssl_certificate_key /etc/letsencrypt/live/devicedomain.com/privkey.pem; + ``` + +13. NGINX now knows how to locate the certificate files for the TLS + Handshake, and decryption. + +### Architecture - CoAP + +![](img/TLS_CoAPArchwDTLS.png) + +In the +case of CoAP we need to issue and install ECDSA certificates onto the +CoAP server(s). As we are using DTLS, rather than TLS, we need to +convert the certificate files from .pem to PKCS12 format for them to be +usable in this context. We then configure the CoAP server -- these are +most commonly Eclipe Californium or libcoap based -- and set up the +KeyStore and TrustStore. As in the case of MQTT, if you choose to +implement mutual authentication, certificates can be installed on +clients, but this is not essential. + +### CoAP Implementation + +1. Set up CoAP server within the on-premises, or cloud environment, and + ensure it has an associated domain that we can prove control of. + +2. Install Certbot -- this is dependent on which OS you are utilising, + command line instructions can be found here: + https://certbot.eff.org/instructions . An example of this is: + + ``` + sudo apt-get update + sudo apt-get install certbot + ``` + +3. Prove domain control (coapserver.domain.com) and obtain an ECDSA + certificate: + + ``` + sudo certbot certonly --standalone --preferred-challenges http --key-type ecdsa -d coapserver.domain.com + ``` + +4. You should now be able to locate the certificate files in + /etc/letsencrypt/live/coapserver.domain.com/. + +5. Locate files: fullchain.pem (cert file), and privkey.pem (private + key) + +6. Because we are using DTLS, not TLS we need to convert the .pem files + to PKCS12 format + + ``` + openssl pkcs12 -export -in /etc/letsencrypt/live/coapserver.domain.com/fullchain.pem -inkey /etc/letsencrypt/live/coapserver.domain.com/privkey.pem -out coap-server.p12 -name "coap-server" + ``` + +7. You may need to extract key and certificate from the P12 file: + + ``` + openssl pkcs12 -in coap-server.p12 -nocerts -out coap-server.key -nodes + openssl pkcs12 -in coap-server.p12 -clcerts -nokeys -out coap-server.crt + ``` + +8. Next you will need to configure your CoAP server with DTLS -- the + commands will depend on your chosen CoAP implementation. A popular + option is libcoap where you would perform the following commands: + + Install libcoap: + + ``` + sudo apt install libcoap2 libcoap-dev + ``` + + Configure DTLS on your CoAP server: + + ``` + TBC - CoAP server must be identified + ``` + +9. Ensure CoAP server is running and configured with DTLS. + +10. Test using CoAP Client library: + + ``` + coap-client -m get -u "your-username" -k "your-password" coaps://coapserver.domain.com/resource + ``` + +### Risk Mitigation and Best Practice + +There are several actions we can take to mitigate risk and apply best +practice. These include: + +Enabling encryption of data transmitted using MQTT connections through +Transport Layer Security (TLS) ensures confidentiality and integrity. + +Ensure you regularly check for and apply any updates and patches +released by your MQTT software vendor. You may need to update your +broker, clients and libraries to ensure you are addressing +vulnerabilities as they are discovered. + +Monitoring and intrusion detection practices are critical in both MQTT +and CoAP environments to identify and respond to suspicious activity on +either network. + +In a CoAP based environment ensure both DTLS and ECDSA are utilised. The +combination of the two will provide the best security and the best +performance. + +Key rotation is important in both MQTT and CoAP. The shorter the life of +your keys the more secure your environment is, as any vulnerability +relating directly to the key in use is mitigated by rotating to the new +key. It means there is only a limited time attackers have to 'break' +your cryptographic key and assume control of your data and systems. With +Let's Encrypt, certificates have a maximum lifespan of 90 days, and they +are rotated automatically with the use of Certbot. + +Key Storage is also very important and in the case of any key and secret +storage, these assets are best held within an HSM, whether it be +hardware or software based. + +### Feasibility Assessment + +**Technical Feasibility** + +Certificate Issuance and Management + +By using a combination of Let's Encrypt and Certbot certificates can be +successfully issued and installed in both the MQTT and CoAP use cases. +Certbot ensures that certificates are rotated as required to provide +continuity of valid certificates on the server or device we are +protecting. + +Certificate Details + +The certificates issued by Let's Encrypt are in .pem format. This format +is suitable for MQTT but not for CoAP. However, CoAP can utilise a .p12 +certificate file which can be derived from converting a .pem file into +this format. CoAP also requires the use of an ECDSA based certificate +which utilises an Eliptic Curve based algorithm for encryption. In this +way we can cover both use cases successfully. + +MQTT Broker Configuration + +Redback Operations use both Mosquitto and HiveMQ Brokers, and both of +these options do support TLS. + +**Financial Feasibility** + +The above solutions are all free of charge, so pose a feasible option +from a financial perspective. The components are Certbot to handle +certificate automation, and Let's Encrypt to issue free digital +certificates. These tools are presented with a recommendation to utilize +a Mosquitto MQTT broker which is also free of charge. + +**Operational Feasibility** + +The proposed solution is relatively simple to deploy and incorporate +into operational process as a standard across the organization. It can +be incorporated into the management and associated development of +Redback Operations end points and does not add great complexity to +current processes. The benefit of standardizing the use of this TLS +solution for MQTT and CoAP is that it greatly reduces risk of data +compromise and improves the overall security posture of the +organization. This is a lightweight solution that should not jeopardise +performance or scalability of Redback Operations product offering. + +**Security Feasibility** + +The addition of TLS for MQTT and DTLS for CoAP will each add great +security benefit as it results in encrypted data hidden from attackers +or eavesdroppers within the Redback environment. It also protects data +from being tampered with. The other benefit for these solutions is +authentication. These security protocols allow a process of +authenticating a server to a client to ensure they are communicating +with the legitimate machine. + +### Change Management + +**Planning**: +- Define objectives and scope. +- Define current state. +- Define proposed future state. +- Assess current knowledge and skill level for this solution. +- Engage current stakeholders including developers of IoT and other + appliance code, owners of end points including authority for current + MQTT infrastructure, Project Team Leaders, Organisation Leaders. + +**Design and Configuration**: +- Design TLS for MQTT solution, configuration, and security policies. +- Design DTLS for CoAP solution, configuration, and security policies. +- Record all planning and design content within Business and + Implementation Plan Document. + +**Pilot Implementation**: +- Set up and configure TLS certificates and MQTT brokers and clients for + single use case. +- Set up and configure DTLS certificates and CoAP brokers and clients for + single use case if available. + +**Testing and Validation**: +- Validate and record step-by-step guide for use as an enablement tool. +- Perform functional, security, and performance testing. +- Optimize configurations as needed. + +**Org-wide Deployment**: +- Ensure enablement materials are in place prior to broader deployment. +- Map additional use cases and applicable projects. +- Plan and execute deployment of solution to wider organisation. + +**Post-Deployment**: +- Monitor, maintain, and manage certificates. +- Update documentation and provide training. +- Review and implement improvements. diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/TLS_Proof_of_Concept_plus_automation.md b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/TLS_Proof_of_Concept_plus_automation.md new file mode 100644 index 000000000..48c92ee28 --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/TLS_Proof_of_Concept_plus_automation.md @@ -0,0 +1,326 @@ +--- +sidebar_position: 2 +--- + +# **Certbot – Let's Encrypt TLS solution for Mosquitto MQTT broker** + +## Proof of Concept + +### Retrospective Review + +| Version | Modified By | Date | Changes Made | +|---------|-----------------|------------|-------------------------------------------------------------------------------------------------| +| v1.0 | Candice Smith | 03/09/2024 | Document Creation draft steps for MQTT Server TLS Implementation | +| v2.0 | Shalom Ingabo | 05/09/2024 | Updated all process steps with confirmed process and added screenshots following technical PoC. | +| v3.0 | Candice Smith | 05/09/2024 | Final formatting of document including division of testing categories, Out of Scope items, etc. | +| v4.0 | Candice Smith | 20/09/2024 | Added Manik’s script + + +# Steps taken and validated during PoC + +## Set Up Test Environment + +**Step 1: Set up EC2 instance** + +Created a new security group to allow inbound rules for SSH, HTTPS and MQTT (1883 for secure MQTT and 8883 for non-secure MQTT). Since it was only for test purposes, I allowed access source from any IP address, however, in the case of production, this needs to be hardened through IP address access control to allow only the necessary IP addresses for security purposes. + +![](img/TLS_PoC_Launchinst.png) + +Launch instance and connect via SSH using command: +``` +ssh –i /path/to/your-key.pem ubuntu@ +``` + + +**Step 2: Link your Domain to the instance** + +Created a domain using AWS called tlsoluttions.com + +We used Route 53 on AWS to create a hosted zone for our domain tlsoluttions.com and did some configurations on the A record to point to our running cloud server instance + +![](img/TLS_PoC_Route53.png) + +Tested domain link using domainchecker to ensure that our domain was being hosted using the IP address of the running instance (takes about 60 seconds for changes to be applied.) + + + +## Set Up Test Mosquitto Broker + +**Step 3: Install mosquitto** + +Run the commands: +``` +sudo apt update +sudo apt install mosquitto mosquitto-clients +``` +in our running instance. This commands updates and install the mosquitto broker to support the MQTT protocol + +**Step 4: Configure mosquitto for tls** + + Edited the mosquitto configurations file to support secure connections by running the command: + ``` + sudo nano /etc/mosquitto/conf.d/default.conf + ``` + +Add the following code to enable TLS: + +``` +listener 8883 + +cafile /etc/letsencrypt/live/mqttserver.domain.com/chain.pem + +certfile /etc/letsencrypt/live/mqttserver.domain.com/fullchain.pem + +keyfile /etc/letsencrypt/live/mqttserver.domain.com/privkey.pem + +tls_version tlsv1.2 +``` + +Explanation of the above code + +listener 8883 specifies the port for TLS connections (default is 8883 for TLS). + +cafile points to the CA certificate file (part of the Let's Encrypt chain). + +certfile points to your server certificate. + +keyfile points to your private key. + +tls_version specifies the minimum TLS version to use. + + + +Saved the file then restarted mosquitto using command: +``` +sudo systemctl restart mosquito +``` + + +## Set Up Certbot and Let’s Encrypt Solution + +**Step 5: Install Certbot for Let’s Encrypt TLS Certificates with Apache** + +Install Certbot and Apcahe plugin using command +``` +Sudo apt install certbot python3-certbot-apache –y +``` + +Obtain SSL Certificates using certbot by running the command: +``` +sudo certbot –apache –d tlsoluttions.com -d www.tlsoluttions.com +``` + +![](img/TLS_PoC_codeexample1.png) +![](img/TLS_PoC_codeexample2.png) + +[successful certificate generation] + +In the above command, certbot uses the Apache plugin to automaticallly configure SSL for our site. Certbot will ask you to choose whether you want to redirect HTTP traffic to HTTPS (which is recommended) + +Verify Apache SSL configurations by running the command : +``` +sudo nano /etc/apache2/sites-available/000-default-le-ssl.conf +``` + +You should be able to see the following lines which tells Apache to use Let’s Encrypt certificates for your domain + +![](img/TLS_PoC_codeexample3.png) + +Restart Apache to ensure all changes take effect by running the command: +``` +sudo systemctl restart apache2 +``` + + + + +**Step 6: Set up automatic renewal** + +To force certbot to renew the certificate every day, you can create a cron job that attempts to renew the certificate everyday by running the command: +``` +sudo crontab -e +``` +Add the following line + +![](img/TLS_PoC_Terminal1.png) + +Explanation of the line + +30 2 * * *: This schedules the task to run at 2:30 AM everyday +``` +/usr/bin/certbot renew –force-renewal +``` +This command forces certbot to renew the certificate, even if it has not reached the typical renewal period which is typically 90 days +``` +/var/log/le-renew.log +``` +This appends the output of the command to a log file for review + +To check the list of the active timer, run command: +``` +sudo systemctl list-timers and check for certbot.timer +``` +![](img/TLS_Poc_Terminal2.png) + + + + + + + + + +**Step 7: Testing automatic renewal** + +Let’s Encrypt certificates are valid for 90 days, but with the installation of certbot, the renewal process is automated and can be tested by running the command: +``` +sudo certbot renew –dry-run +``` +![](img/TLS_Poc_Terminal3.png) +[successful automated renewal] + +![](img/TLS_Poc_Ubuntu1.png) +![](img/TLS_Poc_Ubuntu2.png) +[verifying Apache SSL] + + + +# Automation – Script + +**Setup Automation** + +To streamline the deployment and configuration process, this is an automated script that sets up Mosquitto, configures TLS, installs Certbot, and manages SSL certificates. Below is the script used for this PoC: + + + +**The script-** +``` +#!/bin/bash + +sudo apt-get update + +sudo apt-get install -y mosquitto mosquitto-clients apache2 certbot python3-certbot-apache + +sudo tee /etc/mosquitto/conf.d/mosquitto_tls.conf > /dev/null < /dev/null < + +ServerName YOUR_DOMAIN + +ProxyPass /mqtt ws://localhost:1883/ + +ProxyPassReverse /mqtt ws://localhost:1883/ + +ProxyPass /mqttssl wss://localhost:8883/ + +ProxyPassReverse /mqttssl wss://localhost:8883/ + +ErrorLog \${APACHE_LOG_DIR}/error.log + +CustomLog \${APACHE_LOG_DIR}/access.log combined + + + +EOF + +sudo systemctl restart apache2 + +sudo certbot --apache -d YOUR_DOMAIN + +sudo mkdir -p /etc/mosquitto/certs + +sudo cp /etc/letsencrypt/live/YOUR_DOMAIN/fullchain.pem /etc/mosquitto/certs/fullchain.pem + +sudo cp /etc/letsencrypt/live/YOUR_DOMAIN/privkey.pem /etc/mosquitto/certs/privkey.pem + +echo "0 3 * * * certbot renew --post-hook 'systemctl restart apache2 && systemctl restart mosquitto'" | sudo tee -a /var/spool/cron/crontabs/root +``` + +**Steps to use the script** + +Create a new file for the script: +``` +nano new_file.sh +``` +Paste the automated script into the file. Make sure to replace YOUR_DOMAIN with your actual domain name + +Change the script’s permissions to make it executable: +``` +sudo chmod +x new_file.sh +``` +Execute the script to perform the setup: +``` +sudo ./new_file.sh +``` + +# Out of Scope + +Additional steps and information that may be useful during implementation, deemed out of scope for PoC activity. + + + +Alternative Certbot installation methods for various OS’s can be found here:   + + + +Verify config by testing with MQTT Clients + + +``` +mosquitto_sub -h mqttserver.domain.com -p 8883 -t test/topic \--cafile + +/etc/letsencrypt/live/mqttserver.domain.com/chain.pem +``` + + +*You may need to adjust the port -- please review + + + +In the case a client fails to connect, check Mosquitto logs for errors. + + +``` +sudo journalctl -u mosquito +``` + + +Reload Mosquitto config after successful renewal: + + +``` +sudo nano /etc/letsencrypt/renewal-hooks/post/reload-mosquitto.sh +#!/bin/bash +systemctl reload mosquitto +sudo chmod +x /etc/letsencrypt/renewal-hooks/post/reload-mosquitto.sh +``` + + +# Proof of Concept Outcome + +The outcome of this PoC has been to validate the process for the successful deployment of Certbot and Let’s Encrypt to secure a Mosquitto MQTT broker stored on a server utilising Apache as the operating system. + + + +Not only does this provide a validated process for future TLS deployments but also provides a guide to creating a testing environment for any future proof of concept requirements resulting in a much more efficient process and more focus on testing the new technologies rather than the testing environment. + + + +This PoC has resulted in the successful testing of the Certbot – Let's Encrypt TLS solution as applied to our test MQTT broker, with the successful renewal of the deployed certificate. All this is also captured in an easy to run script which will deploy a Mosquitto broker with TLS. + diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/_category_.json b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/_category_.json new file mode 100644 index 000000000..66e5ad8aa --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/_category_.json @@ -0,0 +1,8 @@ +{ + "label": "Secure Code Development", + "position": 1, + "link": { + "type": "generated-index", + "description": "Flutter and MQTT docs" + } +} diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/adjusting-mac.md b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/adjusting-mac.md new file mode 100644 index 000000000..f1e9601bc --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/adjusting-mac.md @@ -0,0 +1,36 @@ +--- +sidebar_position: 10 +--- + +# Adjusting MAC address anonymization for the MQTT Manager +Proposed changes for MQTT + +:::info +**Author:** Rinor Gimolli +::: + +The code, using Python, aims to use data anonymization of client information – more +specifically client names and client MAC addresses. The earlier code did this however, at a +request, the idea was to scramble the MAC address into a alphanumeric ID – with the option +to convert it back. + +**Initial Code:** + +![Initial Code](img\mac-initial.jpg) + +**Code After Changes** + +![After Code](img\mac-changes.jpg) + +This update hashes the MAC address using MD5, to the encode it in Base64, then it shortens it to 10 +characters. This is used to create an alphanumeric ID. Due to these changes, 2 libraries need to be +imported as shown below. + +``` +import base64 +import hashlib +``` + +Although with these changes reversing to get the original MAC address still isn’t possible, it is still the +most plausible method. For that to happen we would have to convert the hashes into encryption, +which in itself is riskier \ No newline at end of file diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/flutter-best-practice.md b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/flutter-best-practice.md new file mode 100644 index 000000000..ab311638c --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/flutter-best-practice.md @@ -0,0 +1,143 @@ +--- +sidebar_position: 12 +--- + +# Best Practices for Security for Flutter Application + +Research Piece + +Flutter is a mobile app development system that supports the cross-deployment of +apps in programming. + +### Code obfuscation + +- Flutter apps should be equipped to prevent hackers from reverse engineering the +app code and leaking strings, methods, API keys and class names. Data should not +be stored in plain text. Techniques such as obfuscation can hide functions and class +names compiled in Dart code. + +### API key security + +- Restrictions should be applied to limit applications, websites and IP addresses that +can access API keys. Encryption and decryption methods should be applied to API +keys on runtime. API keys should not be tracked on the repository to minimise the +exposure of values. + +### Flutter jailbreak detection + +- To prevent security threats and safeguard applications from a jailbroken device, +the package ‘Flutter_jailbreak_detection’ can be used. This will determine if the +app is being run on a compromised device. These devices are subject to more +privilege and malware or virus threats. Jailbreak detection will require RootBeer +on Android and DTTJailbreakDetection on iOS. + +### Secure network connections + +- A Transport Secure Layer (TLS) should be used to exchange information and +certificate pinning should be implemented to protect connections and attackers +from accessing data via compromised certificates. + +### Utilise required permissions only + +- Permissions can be enabled to access hardware and APIs through the app. By +default, all plugins should be disabled if they contain unnecessary permissions. + +### User data security + +- Where there is a need to store personally identifiable information or any other +sensitive data, the Flutter_secure_storage package should be used. + +### Protection through background snapshots + +- Flutter apps are vulnerable to exposing sensitive data through the feature that +showcases a snapshot of the previous state of the app. The secure_application +package can protect this content. + +### Implement local authentication + +- Local_auth should be used as a plugin that supports authentication for Flutter +apps. Biometric authentication should be implemented to protect apps storing +payment information and local authentication should be used to provide +protection in the event that the device is lost or stolen. + +### Developer identity security + +- Encryption should be applied where there is a risk that the app may expose the +identity of the developer. Sensitive files should be encrypted with GPG where they +can be identified as key.jks and keystore.properties. + +### CI infrastructure security + +- Code should be developed into a shared repository and vulnerabilities should be +monitored in addition to updating Virtual Machine. Sensitive data should only be +included in the secret settings. + +## Secure Coding for Flutter + +### HTTPS + +- A secure layer must be inserted between the TCP communication layer and +Transport Layer Security (TLS) to ensure the communication method for client- +server applications is secure. + +- Upon connecting to the server, the client will receive the public key and all +messages sent will be encrypted with only the server being able to decrypt +messages through the private key. This prevents packet sniffers from reading the +request details. + +- Communication should only be had with HTTPs endpoints and the server must +either show the user a warning or issue a certificate that has been signed by +authorities. + +- All URLs should commence with HTTPS. The http package can still be used. + +![Flutter HTTP](img\flutter-http.jpg) + +### Jailbroken and rooted devices + +- Jailbroken devices allow attackers to bypass security measures and import +malware on devices. + +- Installation of flutter_jailbreak_detection will detect if the app is running on a +device that is jailbroken or rooted. + +- It is compatible with Android devices and known as Root Beer and also on iOS +devices known as DTT Jailbreak Detection + +![Flutter Jailbreak](img\flutter-jailbreak.jpg) + +### Encryption + +- Data should be encrypted in the Flutter app through converting the text into code +to ensure it is only accessible through a key or password. This will protect it from +unauthorised access + +- Algorithms such as AES or RSA can be used to encrypt data + +- Key management systems or secure storage locations + +- SSL/TLS protocols can be used to encrypt data in transit and secure +communication channels between the client and server + +- Using certificate pinning can ensure the app only communicates with servers that +have a trusted SSL/TLS certificate + +### Authenticating users and authorisation + +- Multi-factor authentication should be used to verify the identity of the users and +improve security mechanisms + +- Rate limiting protocols could be used to prevent attackers from guessing a +password a certain amount of times and time limitations can be set to prevent +repeated attempts. + +- User credentials should be store via hashing and salting techniques to ensure +passwords are not readable and vulnerable in data breach incidents + +- Access controls should be implemented to prevents certain users from accessing +only data that is required for their role and minimises the risk of unauthorised +access + +### Obfuscation + +https://paulmburu.hashnode.dev/securing-a-flutter-app diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_CoAPArch.png b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_CoAPArch.png new file mode 100644 index 000000000..2e3f1b2dc Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_CoAPArch.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_CoAPArchwDTLS.png b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_CoAPArchwDTLS.png new file mode 100644 index 000000000..33428f846 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_CoAPArchwDTLS.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_MQTTArch.png b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_MQTTArch.png new file mode 100644 index 000000000..3d87f81a6 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_MQTTArch.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_MQTTArchwTLS.png b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_MQTTArchwTLS.png new file mode 100644 index 000000000..06b9f68a2 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_MQTTArchwTLS.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_P1Architecture.png b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_P1Architecture.png new file mode 100644 index 000000000..0f8559783 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_P1Architecture.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_PoC_Launchinst.png b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_PoC_Launchinst.png new file mode 100644 index 000000000..32c17f9a9 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_PoC_Launchinst.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_PoC_Route53.png b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_PoC_Route53.png new file mode 100644 index 000000000..e5a7c421a Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_PoC_Route53.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_PoC_Terminal1.png b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_PoC_Terminal1.png new file mode 100644 index 000000000..d66918d44 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_PoC_Terminal1.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_PoC_codeexample1.png b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_PoC_codeexample1.png new file mode 100644 index 000000000..bec7861b1 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_PoC_codeexample1.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_PoC_codeexample2.png b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_PoC_codeexample2.png new file mode 100644 index 000000000..ba760cbb0 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_PoC_codeexample2.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_PoC_codeexample3.png b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_PoC_codeexample3.png new file mode 100644 index 000000000..fa9012383 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_PoC_codeexample3.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_Poc_Terminal2.png b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_Poc_Terminal2.png new file mode 100644 index 000000000..c540d5fa1 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_Poc_Terminal2.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_Poc_Terminal3.png b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_Poc_Terminal3.png new file mode 100644 index 000000000..380bca429 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_Poc_Terminal3.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_Poc_Ubuntu1.png b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_Poc_Ubuntu1.png new file mode 100644 index 000000000..516d28d22 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_Poc_Ubuntu1.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_Poc_Ubuntu2.png b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_Poc_Ubuntu2.png new file mode 100644 index 000000000..80160afe0 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_Poc_Ubuntu2.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_RedbackArchitecture.png b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_RedbackArchitecture.png new file mode 100644 index 000000000..048b01940 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_RedbackArchitecture.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_TLShandshake.png b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_TLShandshake.png new file mode 100644 index 000000000..49662a092 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_TLShandshake.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_mTLShandshake.png b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_mTLShandshake.png new file mode 100644 index 000000000..f4abb83e9 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/TLS_mTLShandshake.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/flutter-http.jpg b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/flutter-http.jpg new file mode 100644 index 000000000..9bf3b2c10 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/flutter-http.jpg differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/flutter-jailbreak.jpg b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/flutter-jailbreak.jpg new file mode 100644 index 000000000..cdff0192b Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/flutter-jailbreak.jpg differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/mac-changes.jpg b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/mac-changes.jpg new file mode 100644 index 000000000..6ce1f0787 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/mac-changes.jpg differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/mac-initial.jpg b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/mac-initial.jpg new file mode 100644 index 000000000..9201892f4 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/mac-initial.jpg differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/mqtt-before.png b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/mqtt-before.png new file mode 100644 index 000000000..f4aa8eba1 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/mqtt-before.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/mqtt-sample.png b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/mqtt-sample.png new file mode 100644 index 000000000..4fe895d34 Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/mqtt-sample.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/scr1.png b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/scr1.png new file mode 100644 index 000000000..fc669e6ea Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/scr1.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/scr2.png b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/scr2.png new file mode 100644 index 000000000..5e27fa9dd Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/scr2.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/scr3.png b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/scr3.png new file mode 100644 index 000000000..2d790c98f Binary files /dev/null and b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/img/scr3.png differ diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/project-1-MQTT.md b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/project-1-MQTT.md new file mode 100644 index 000000000..bbb4ce063 --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/project-1-MQTT.md @@ -0,0 +1,28 @@ +--- +sidebar_position: 11 +--- + +# MQTT Summary +Code Adjustments and Project 1 Collabs + +:::info + +**Author:** Rinor Gimolli + +::: + +## Begun collaborations with Project 1 – VR SunCycle SmartBike + +- Reached out to subleader Krishn about potential collaboration + +- They needed assistance with securing data, mainly values from the SmartBike per client + +- Code needed to be adjusted to fit their needs securely + +## How The Code Looked Before Adjustment + +![MGTT Before](img\mqtt-before.png) + +## Sample Codes for Receiving and Sending Through the MQTT + +![MQTT Sample](img\mqtt-sample.png) \ No newline at end of file diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/project1-mqtt-secure-code-review.md b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/project1-mqtt-secure-code-review.md new file mode 100644 index 000000000..307683016 --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/project1-mqtt-secure-code-review.md @@ -0,0 +1,157 @@ +--- +sidebar_position: 13 +--- + +# MQTT Code Review +Secure Code Review for Project 1 + +:::info + +**Author:** Mehak + +::: + +## Secure Coding Review and Improvements for Project 1 + +[**iot/Research/CyberSecurityMQTT/MQTT_data_frame_handler.py at main · redbackoperations/iot · GitHub**](https://github.com/redbackoperations/iot) + +**Overview:** As part of the secure coding review, I have analyzed the provided Python code for potential security vulnerabilities and have outlined areas that need improvement. Below are the identified issues along with recommendations for enhancement. + +1. **Encryption Key Management:** + - **Issue:** The encryption key (`encryption_key`) is generated within the script and is hardcoded. Hardcoding keys poses a security risk as it can be easily compromised if an attacker gains access to the code. + - **Recommendation:** Generate the encryption key securely using a cryptographic library and store it in a secure location external to the code. + +2. **Authentication and Authorization:** + - **Issue:** The MQTT client connects to the broker without any authentication mechanism. Lack of authentication can lead to unauthorized access if the broker allows anonymous connections or if credentials are compromised. + - **Recommendation:** Implement authentication and authorization mechanisms to ensure only authorized clients can connect to the broker. + +3. **Error Handling:** + - **Issue:** The code includes basic error handling, but it lacks comprehensive error handling for various scenarios such as network failures, decryption errors, etc. + - **Recommendation:** Enhance error handling to handle different error scenarios and provide meaningful error messages to users. + +4. **Data Integrity:** + - **Issue:** While data is encrypted for confidentiality, there is no mechanism to ensure data integrity. Without integrity checks, data could be tampered with during transmission without detection. + - **Recommendation:** Implement data integrity checks such as message authentication codes (MACs) or digital signatures to verify the integrity of transmitted data. + +5. **Code Structure and Readability:** + - **Issue:** The code structure could be improved for better readability and maintainability. Certain methods are lengthy and may benefit from refactoring. + - **Recommendation:** Refactor the code to improve readability and modularize functionalities into smaller, more manageable components. + +6. **Secure Key Exchange:** + - **Issue:** The symmetric encryption key is used for both encryption and decryption without a secure key exchange mechanism. + - **Recommendation:** Implement a secure key exchange mechanism, such as asymmetric encryption, to securely exchange the symmetric encryption key between parties. + +Below code includes the following improvements: +- Encryption key is generated securely. +- Authentication and error handling are enhanced. +- Data integrity checks are added. +- Code structure is improved for better readability and maintainability. +- Secure key exchange mechanism is implemented. + +``` +python +#!/usr/bin/env python +# coding: utf-8 + +import pandas as pd +import paho.mqtt.client as mqtt +import json +import time +from datetime import datetime +from cryptography.fernet import Fernet + +class MQTTDataFrameHandler: + def __init__(self, broker_address, topic, encryption_key): + self.broker_address = broker_address + self.topic = topic + self.client = mqtt.Client() + self.client.on_message = self._on_message + self.encryption_key = encryption_key # Pass encryption key as argument + self.cipher_suite = Fernet(encryption_key) # Initialize cipher suite + self.data = None + self.error = None + self.max_retries = 3 + self.retry_interval = 5 + + def _on_message(self, client, userdata, message): + try: + encrypted_data = message.payload + data_json = self.cipher_suite.decrypt(encrypted_data).decode('utf-8') + self.data = pd.read_json(data_json) + self.data['timestamp'] = time.time() + except Exception as e: + self.error = str(e) + + def encrypt_value(self, value): + return self.cipher_suite.encrypt(str(value).encode('utf-8')) + + def decrypt_value(self, encrypted_value): + return self.cipher_suite.decrypt(encrypted_value).decode('utf-8') + + def create_json_payload(self, dataframe, user_id=None): + df_anonymized = dataframe.copy() + + if 'incline' in df_anonymized.columns: + df_anonymized['incline'] = df_anonymized['incline'].apply(lambda x: self.encrypt_value(x) if x else x) + + if 'resistance' in df_anonymized.columns: + df_anonymized['resistance'] = df_anonymized['resistance'].apply(lambda x: self.encrypt_value(x) if x else x) + + data_json = df_anonymized.to_json(orient='split') + + payload = { + 'timestamp': datetime.utcnow().isoformat(), + 'data': json.loads(data_json) + } + + if user_id: + payload['user_id'] = user_id + + return json.dumps(payload) + + def receive_data(self, timeout=10): + retries = 0 + while retries < self.max_retries: + try: + self.client.connect(self.broker_address, 1883, 60) + self.client.subscribe(self.topic) + self.client.loop_start() + start_time = time.time() + while self.data is None and (time.time() - start_time) < timeout: + if self.error: + print(f"Error while receiving data: {self.error}") + break + self.client.loop_stop() + return self.data + except Exception as e: + print(f"Connection error: {e}. Retrying in {self.retry_interval} seconds...") + retries += 1 + time.sleep(self.retry_interval) + print("Max retries reached. Failed to receive data.") + return None + + def send_data(self, df, user_id=None): + retries = 0 + while retries < self.max_retries: + try: + json_payload = self.create_json_payload(df, user_id) + encrypted_payload = self.cipher_suite.encrypt(json_payload.encode('utf-8')) + self.client.connect(self.broker_address, 1883, 60) + self.client.publish(self.topic, encrypted_payload) + self.client.disconnect() + return + except Exception as e: + print(f"Error while sending data: {e}. Retrying in {self.retry_interval} seconds...") + retries += 1 + time.sleep(self.retry_interval) + print("Max retries reached. Failed to send data.") + +def main(): + broker_address = "test.mosquitto.org" + topic = "test/topic" + encryption_key = Fernet.generate_key() # Generate encryption key + handler = MQTTDataFrameHandler(broker_address, topic, encryption_key) + +if __name__ == "__main__": + main() +``` diff --git a/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/secure-code-review-methodologies.md b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/secure-code-review-methodologies.md new file mode 100644 index 000000000..5e308f49a --- /dev/null +++ b/docs/cybersecurity/SecDevOps Team/Archived Files/secure-code/secure-code-review-methodologies.md @@ -0,0 +1,174 @@ +--- +sidebar_position: 18 +--- + +:::info + **Last Edited:** 6 May 2024. **Author:** Tushar Sharma **Version:** 3.0. +::: + +# Secure Code Review + +Introduction to guidelines and methodologies for performing secure code reviews, covering key principles, common vulnerabilities, and best practices. + +## Secure Code Review + + Secure code review is a critical process of reviewing the source code of an application aiming to identify and mitigate vulnerability, threats that could have been unintentionally placed during development [1]. This involves the examining of source code to find the potential weaknesses, loopholes or bugs that could be exploited by attackers. Beyond safeguarding against potential exploits by malicious actors, it also plays a vital role to improve the overall quality of the codebase. It also uncovers the code inefficiencies, poor coding practices, and potential points of failure. Therefore, many organizations are investing in secure code review processes for not only mitigating security risks, but also create a strong foundation for the long-term success of their projects [2]. + +## Methods and Practices for Enhancing Software Security + +There are various methods and practices that contribute to fortifying applications against cyber threats. While each approach serves its purpose and strategies to enhance Security. + +### Security Requirements Analysis and Threat Modeling + +Security requirements analysis and threat modeling are processes that help identify security needs and potential risks during software development. They ensure that security is considered right from the start and help decide which security measures are most important. However, they don't look at the code itself in as much detail as secure code review does. + +### Static and Dynamic Application Security Testing (SAST and DAST) + +Static and dynamic application security testing, known as SAST and DAST, examine software differently. SAST looks at the source code for vulnerabilities without running the program, while DAST tests the running application for vulnerabilities as it operates. Although these methods can uncover vulnerabilities, they might not catch all types of security issues and have limitations in their coverage. + +### Code Signing + +Code signing is a process that confirms the authenticity and integrity of code, which helps maintain its integrity. While code signing ensures that the code hasn't been tampered with, it doesn't directly deal with or resolve security vulnerabilities present within the codebase. + +## Why Choose Secure Code Review? + +### Proactive Vulnerability Detection + +Secure code review stands as a proactive measure in software development, ensuring that potential security vulnerabilities are identified and addressed before they pose risks to the system. By conducting thorough reviews of the codebase during the development phase, teams can prevent potential exploitation by attackers, safeguarding the integrity and security of the application. By regularly reviewing and discussing security best practices and common vulnerabilities, developers gain a deeper understanding of secure coding principles and learn to identify potential security risks in their code independently. + +For example, suppose a development team is building a web application that handles sensitive user data, such as financial information. During a secure code review, a developer identifies a section of code that doesn't properly validate user input before processing it, potentially exposing the application to SQL injection attacks. By catching this vulnerability early in the development process through code review, the team can implement proper input validation mechanisms to prevent such attacks, thereby enhancing the application's security posture. + +### Integration with Development Process + +Secure code review seamlessly integrates with the software development lifecycle, making it a cost-effective and efficient method for ensuring security. Integrating secure code review into the development workflow allows for continuous monitoring and improvement of security practices. As developers review each other's code and collaborate on identifying and resolving vulnerabilities, they gain valuable insights into secure coding practices and common security pitfalls. This iterative process helps build a stronger security culture within the organization and empowers developers to write more secure code from the start. + + +### Comprehensive Coverage + +Secure code review offers a distinct advantage over other methods by providing a rough examination of the codebase. While other security practices may focus on specific aspects of security, such as system defenses or runtime testing, secure code review delves deeply into the code itself, examining every line for potential vulnerabilities. +This comprehensive approach allows secure code review to uncover both common security weaknesses, such as input validation errors or insecure data handling, as well as more obscure vulnerabilities that may evade automated testing tools or go unnoticed during runtime analysis. +For example, a static analysis tool may flag a potential SQL injection vulnerability in a particular code snippet, but only a human reviewer conducting a thorough code review may notice subtle variations in input validation logic that could also lead to injection attacks. By providing this level of scrutiny, secure code review helps organizations bolster their defenses against a wide range of security threats, from the most common to the most sophisticated. + + +### Continuous Improvement + +Secure code review does the continuous improvement within development teams by encouraging adherence to secure coding practices, knowledge sharing, and skills development. + +While other security practices play crucial roles, secure code review stands out as a proactive and comprehensive approach for ensuring software security. By addressing vulnerabilities at the source code level, organizations can build resilient software systems that withstand cyber threats. Prioritizing secure code review is fundamental for mitigating security risks and ensuring the long-term success of software projects. + + +## Guide to Secure Code Review: A Step-by-Step Approach: + +Conducting a secure code review is a critical process in software development aimed at identifying and mitigating security vulnerabilities within the codebase. Whether you're a seasoned developer or new to the field, following a structured approach can help ensure thorough examination and effective remediation of security issues. Here’s steps involved in performing a secure code review: + +![Secure-Code-Review-Process](img/scr1.png) + +### 1. Understand the Application and its Requirements: + +The first step involves obtaining a thorough understanding of the application's functionality, architecture, and specific security requirements. This knowledge acts as a roadmap for the review process, aiding in the effective prioritization of areas to focus on. Understanding the intricacies of the application's design and purpose is essential for conducting a targeted and efficient code review, ensuring comprehensive coverage of potential security vulnerabilities. Additionally, having a basic understanding of code is imperative to effectively assess the codebase. + +### 2. Set Up Your Development Environment: + +Ensure that you have access to essential tools, version control systems, and designated code review platforms. Familiarize yourself with the structure and organization of the codebase to facilitate seamless navigation during the review process. In our case, access to the project will be facilitated through a GitHub repository, where you will initiate a Git pull request to retrieve the codebase. +Once accessed, consider conducting preliminary tests on the codebase to ascertain its functionality and identify potential areas of concern. Additionally, you have the flexibility to choose between conducting the secure code review on your local host machine or within a Linux environment, depending on your preference and requirements. +To enhance the effectiveness of the code review, consider utilizing multiple scanning tools such as Snyk, SonarQube, bandit and many more. These tools can assist in identifying security vulnerabilities, ensuring a comprehensive evaluation of the codebase. + + +### 3. Define Review Criteria and Objectives + +Establishing clear criteria and objectives for the code review is essential for ensuring a focused and effective evaluation of the codebase. Begin by defining the security standards and compliance requirements that the application must adhere to. Identify key areas of concern based on factors such as the application's sensitivity, potential impact of security breaches, and industry-specific regulations. +By setting clear criteria and objectives, you provide a framework for conducting the code review, guiding reviewers to focus on the most critical aspects of security. This systematic approach ensures that the review process is thorough, targeted, and aligned with the overall security goals of the organization. + +### 4. Review Execution + +Execute the code review process by systematically examining the source code for potential security vulnerabilities. This can be achieved through a combination of manual inspection techniques and automated scanning tools. +During the review, you can start with common security flaws such as injection attacks (e.g., SQL injection, XSS), authentication issues (e.g., weak password policies, improper session management), and data validation errors (e.g., lack of input validation, insufficient output encoding). +By following an approach that combines manual scrutiny with automated analysis, you can effectively identify and address security vulnerabilities within the codebase. This ensures that the application is fortified against potential threats and adheres to established security standards and best practices. + +### 5. Identify Security Vulnerabilities + +As you delve deeper into the codebase, consistently applying the review process, you'll begin to uncover potential security vulnerabilities. It's essential to maintain consistency and persistence during this phase, as it may initially be challenging to identify vulnerabilities. Don't be discouraged if you encounter difficulties in finding your first vulnerability; persistence is key. Keep iterating through the code, scrutinizing each component thoroughly, and remain vigilant for any signs of security weaknesses. Remember, every vulnerability identified brings the application one step closer to enhanced security and resilience. While conducting the review, it's vital to do more than just spotting vulnerabilities; take the time to understand why these vulnerabilities exist in the first place [2]. + +### 6. Document Findings and Provide Recommendations: + +Documenting findings is critical for effective code review process. Documents should have identified vulnerabilities, their severity, and proposed fixes in your documentation. Provide actionable recommendations for remediation, prioritizing vulnerabilities based on their potential impact on system security. +This documentation ensures that developers have clear guidance for addressing security issues and helps stakeholders understand the security posture of the application. +For documentation, we will provide you with a template, where you will document all your findings. + + +In conclusion, these steps offer a pathway to contribute significantly to the security and reliability of software applications. + +## Secure Code Review Checklist + + + +![secure-code-review-checklist](img/scr2.png) + + +![secure-code-review-checklist](img/scr3.png) + +## Key Concepts of Secure Code Review + +### Security Principles + +There are some guidelines to secure the system, and these guidelines are Security Principles. These principles serve as the foundation for cybersecurity practices by guiding to mitigate the risk, securing data, and ensuring confidentiality, integrating, and availability of information [3]. There are lot of principles, some of them I will be explaining here: + +- Principle of Least Privilege: This principle restricts the privileges that are granted. Least Privilege states that users and processes should be granted only the minimum level of access or permissions necessary to perform their legitimate task. This design of security reduces the attack surface. + +- Principle of Fail-Safe Defaults: This design of security encourages the system or software secure default settings. In simple language, at time of any failure, whether it is network failure, or misconfiguration, the system should fall back to secure state. This helps to prevent unauthorized access and data breaches. + +- Principle of Complete Mediation: Principle of Complete Mediation states the validating and enforcing access controls for every request or operation performed within a system. This ensures only validated users can access the controls, therefore it prevents security bypass. + + +## Common Vulnerabilities and how to detect them + +Various vulnerabilities are commonly found across different codebases. To identify these vulnerabilities, developers and secure code reviewers can refer to two widely recognized lists: CWE and CVE. +Common Weakness Enumeration (CWE): CWE is a publicly available list of software security weaknesses that identifies and categorizes common software vulnerabilities. It helps developers and security professionals understand potential security risks and provides a common language for discussing and addressing these weaknesses. +Common Vulnerabilities and Exposures (CVE): CVE is a database of publicly known security vulnerabilities and exposures used to identify specific security issues in software and hardware systems. Each CVE entry provides a unique identifier, description, and relevant details to track vulnerabilities and ensure proper patch management and mitigation strategies. +Secure code reviewers can use these lists to identify common vulnerabilities in codebases. Here are some of the most prevalent vulnerabilities, along with ways to detect them: + +- CWE-79: Cross-Site Scripting (XSS): This occurs when user inputs are not properly sanitized, allowing attackers to inject malicious scripts into web pages. We can detect this vulnerability by looking after unsanitized user inputs in web applications. +- CWE-89: SQL Injection: It Happens when user inputs are used to construct SQL queries without proper parameterization, leading to injection attacks. We can check for raw SQL queries with direct user inputs. +- CWE-22: Path Traversal: Path Traversal occurs when a program improperly validates user-supplied file paths, allowing attackers to access restricted files or directories. Detecting this vulnerability involves looking for file operations that use user-controlled inputs, especially those involving directory traversal patterns like ../. To prevent path traversal, we need to validate and sanitize all file paths, restrict file access to specific directories, and avoid direct file system manipulation based on user input. +- CWE-434: Unrestricted File Upload: Unrestricted File Upload happens when an application allows file uploads without proper validation, potentially permitting malicious files. To detect this vulnerability, examine code that handles file uploads and ensure it validates file types and sizes. Implement security controls to allow only specific file formats and scan uploaded files for malware or suspicious content. +- CWE-120: Buffer Overflow: This happens when a program writes data beyond the allocated memory buffer, leading to crashes or code execution. This vulnerability can be detected by analyzing code for unbounded buffers and reviewing array operations to ensure proper bounds checking. +- CWE-732: Improper Authorization: Improper Authorization occurs when a system does not enforce authorization checks which allows the unauthorized access to resources or functions. This vulnerability can be detected by reviewing authentication and authorization logic, ensuring proper role-based access control, and confirming that all sensitive operations are properly protected. Implement strict permission checks and ensure a robust authorization model. +- CWE-94: Code Injection: Code Injection occurs when an application allows execution of arbitrary code due to insufficient input validation or unsanitized inputs. Detecting this vulnerability involves analyzing code that constructs executable statements or scripts and ensuring proper validation and sanitization. + + +You can read for the exploited vulnerability here to have an idea of CVE and CWE: +[link](https://www.cyber.gov.au/about-us/view-all-content/alerts-and-advisories/2022-top-routinely-exploited-vulnerabilities) + + +## Common Patterns for Vulnerabilities: + +There are some common patterns or coding practices that often lead to security vulnerabilities. We can ease our work by recognizing these patterns. We can quickly identify high-risk areas in the codebase and recommend necessary changes. Here are some of the most common patterns which lead to vulnerability: +- Direct Use of User Inputs: Most of the time in user input like constructing SQL queries or system commands, it creates a high risk for injection attacks. We should ensure that user inputs are properly sanitized, validated, and parameterized to prevent SQL Injection, Cross-Site Scripting (XSS). +- Improper Error Handling: Detailed error messages should not be revealed as it can leak the system information or data can be exploited by attackers to gain insights into the application's structure or identify potential weak points. Reviewers should check for error messages that disclose sensitive information and recommend a more generic approach to error handling to avoid information leakage. +- Hardcoded Credentials: Storing sensitive information like passwords, API keys, or security tokens directly in the code is a significant security risk. These hardcoded credentials can be easily extracted by attackers. +- Insecure Configuration: Configuration files contains the security risks due to the reason exposed ports, weak permissions, or unencrypted connections, can lead to unauthorized access and other security issues. Reviewers should examine configuration files for these risks and recommend secure configuration practices, such as limiting access to only necessary users, using encrypted connections, and enforcing strong permissions. +- Inadequate Session Management: Improper handling of user sessions can lead to session hijacking or unauthorized access. We should check for secure session management practices, like generating unique session identifiers, implementing session expiration, and protecting sessions with encryption. Additionally, ensure that session tokens are not exposed or accessible to unauthorized users. +  + +## Some important documents for upskilling and practices: + +- OWASP Code Review Guide: +[link](https://owasp.org/www-pdf-archive/OWASP_Code_Review_Guide_v2.pdf) + +- Secure Code Review Best Practices [cheat sheet included]: +[link](https://blog.gitguardian.com/secure-code-review-cheat-sheet-included/#:~:text=Some%20popular%20SCA%20tools%20include%3A%201%20GitHub%20Dependabot,2%20Snyk%20Open%20Source%203%20Synopsys%20Black%20Duck) + +- Building a Practical Secure Code Review Process: +[link](https://betterappsec.com/building-a-practical-secure-code-review-process-cdee8ebf68c8) + +- Secure Coding Practices Checklist: +[link](https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/02-checklist/05-checklist.html) + + + +## References + +[1] Threat Intelligence, “Secure Code Reviews: What is it, Benefits and Checklist,” 10 March 2023. [Online]. Available: https://www.threatintelligence.com/blog/secure-code-reviews. +[2] The Cloud Native Experts, “What Is Secure Code Review? Process, Tools, and Best Practices,” 5 November 2023. [Online]. Available: https://www.aquasec.com/cloud-native-academy/devsecops/secure-code-review/. +[3] J. Mlakar, “InfoSec Design Principles – 8 Security Principles To Implement,” MlakarTechTalk, 16 April 2019. [Online]. Available: https://www.mlakartechtalk.com/infosec-design-principles-8-security-principles-to-implement/. +