Skip to content

Latest commit

 

History

History
337 lines (298 loc) · 19.8 KB

sec-design.md

File metadata and controls

337 lines (298 loc) · 19.8 KB

BUSINESS POSTURE

This project, named Sunflower, is an example Android application showcasing modern Android development best practices. It is designed to demonstrate the use of Architecture Components, Material Design, and other recommended Android libraries. The primary business goal is to provide a learning resource for Android developers, illustrating how to build robust, maintainable, and visually appealing Android applications.

  • Business Priorities:

    • Provide a high-quality, practical example of modern Android development.
    • Showcase best practices and recommended libraries.
    • Serve as a learning tool for Android developers of varying skill levels.
    • Maintain code clarity and readability for educational purposes.

  • Business Risks:

    • Misinterpretation of best practices if the example is not carefully crafted.
    • Security vulnerabilities in the example code that could be copied by developers.
    • Outdated dependencies or libraries that could lead to compatibility issues or security concerns in projects that adopt this example.
    • Lack of clarity or documentation, hindering the learning process for developers.

SECURITY POSTURE

The Sunflower project, being a demonstration application, likely has a minimal security posture in its current form. The focus is on functionality and educational value rather than robust security controls.

  • Existing Security Controls:

    • security control: Use of Android Jetpack libraries, which are generally developed with security considerations in mind. Implemented within the application codebase, leveraging libraries like Room for data persistence and Navigation for UI flow.
    • security control: Adherence to Android security best practices as documented by Google. Implemented through code structure and library choices, implicitly following platform recommendations.

  • Accepted Risks:

    • accepted risk: Lack of explicit authentication and authorization mechanisms. Accepted as the application is designed for offline, single-user use and does not handle sensitive user data or server-side interactions.
    • accepted risk: Minimal input validation beyond what is inherently provided by Android UI components and data binding. Accepted as the application's data inputs are primarily controlled by the user interface and are not designed to handle malicious or unexpected input from external sources.
    • accepted risk: No explicit cryptographic measures for data at rest or in transit. Accepted as the application stores non-sensitive data locally and does not communicate over networks.
    • accepted risk: Limited focus on supply chain security for dependencies. Accepted as the project relies on well-established and widely used Android libraries managed through Gradle and Maven Central.

  • Recommended Security Controls:

    • security control: Implement static analysis security testing (SAST) tools in the build pipeline to automatically detect potential code vulnerabilities.
    • security control: Regularly update dependencies to address known vulnerabilities in libraries.
    • security control: Consider adding basic input validation to handle unexpected user inputs more robustly, even for a demo application.
    • security control: If future iterations involve network communication or data sharing, implement appropriate transport layer security (TLS/SSL) and consider server-side security measures.

  • Security Requirements:

    • Authentication: Not applicable in the current scope as it is a single-user, offline application. If user accounts or online features are added, authentication will become a requirement.
    • Authorization: Not applicable in the current scope. If user roles or data access controls are introduced, authorization mechanisms will be needed.
    • Input Validation: While currently minimal, more robust input validation should be considered, especially if the application were to handle data from external sources or user-provided text inputs beyond simple form fields. Validation should be implemented at the application layer, before data is processed or persisted.
    • Cryptography: Not currently required. If sensitive data storage or network communication is introduced, encryption at rest (using Android Keystore or similar) and in transit (TLS/SSL) will be necessary.

DESIGN

The Sunflower project is designed as a single-application Android project, following a modern Android architecture. It is primarily focused on local data management and user interface interactions.

C4 CONTEXT

flowchart LR
    subgraph "User"
        U[User]
    end
    subgraph "Google Play Store"
        GPS[Google Play Store]
    end
    subgraph "Android System"
        AS[Android System]
    end
    subgraph "Sunflower Application"
        SA[Sunflower Application]
    end

    U --> SA
    GPS --> SA: Distribution
    AS --> SA: Runtime Environment

    style U fill:#f9f,stroke:#333,stroke-width:2px
    style GPS fill:#ccf,stroke:#333,stroke-width:2px
    style AS fill:#ccf,stroke:#333,stroke-width:2px
    style SA fill:#fff,stroke:#333,stroke-width:2px
Loading
  • Context Diagram Elements:
    • Element 1:
      • Name: User
      • Type: Person
      • Description: End-user interacting with the Sunflower application on their Android device.
      • Responsibilities: Uses the application to browse plant information, manage a garden, and learn about Android development best practices.
      • Security controls: User is responsible for device security (passcode, biometrics) and for granting necessary permissions to the application.
    • Element 2:
      • Name: Google Play Store
      • Type: System
      • Description: The official app store for Android, used for distributing the Sunflower application to users.
      • Responsibilities: Provides a platform for distributing and updating the application. Performs basic app vetting and malware scanning before publishing.
      • Security controls: Google Play Protect scans apps for malware. Google Play Signing ensures app integrity and authenticity.
    • Element 3:
      • Name: Android System
      • Type: System
      • Description: The Android operating system running on the user's device, providing the runtime environment for the Sunflower application.
      • Responsibilities: Manages application lifecycle, provides system resources, enforces application sandboxing and permissions.
      • Security controls: Android permission system, application sandboxing, system updates and security patches.
    • Element 4:
      • Name: Sunflower Application
      • Type: Software System
      • Description: The Sunflower Android application itself, demonstrating Android development best practices.
      • Responsibilities: Provides plant information, garden management features, user interface, data persistence, and application logic.
      • Security controls: Implements Android security best practices, utilizes secure Android libraries, adheres to permission requests, and performs local data storage securely within the application's sandbox.

C4 CONTAINER

flowchart LR
    subgraph "Android Device"
        subgraph "Sunflower Application Container"
            UI[User Interface (Activities, Fragments, Views)]
            VM[ViewModels]
            Repo[Data Repository]
            DB[Local Database (Room)]
            API[Android System APIs]
        end
    end

    U[User] --> UI: Interacts with
    UI --> VM: Data Binding, UI Logic
    VM --> Repo: Data Access
    Repo --> DB: Local Data Persistence
    Repo --> API: System Features (e.g., Camera, Notifications)
    API --> AS[Android System]: System Services

    style UI fill:#f9f,stroke:#333,stroke-width:2px
    style VM fill:#f9f,stroke:#333,stroke-width:2px
    style Repo fill:#f9f,stroke:#333,stroke-width:2px
    style DB fill:#ccf,stroke:#333,stroke-width:2px
    style API fill:#ccf,stroke:#333,stroke-width:2px
Loading
  • Container Diagram Elements:
    • Element 1:
      • Name: User Interface (Activities, Fragments, Views)
      • Type: Container - Android UI Components
      • Description: The visual part of the application, built using Android Activities, Fragments, Layouts, and Views. Responsible for user interaction and presentation.
      • Responsibilities: Displaying information to the user, handling user input, navigation, and visual presentation.
      • Security controls: Input validation within UI components, following Android UI security guidelines, protection against UI-based vulnerabilities (e.g., clickjacking, if applicable in this context).
    • Element 2:
      • Name: ViewModels
      • Type: Container - Android Architecture Component
      • Description: Manages UI-related data and lifecycle, providing data to the UI and handling UI logic. Separates UI from data sources.
      • Responsibilities: Holding and managing UI data, handling business logic related to UI interactions, surviving configuration changes.
      • Security controls: Data sanitization before displaying in UI, implementing UI-related authorization checks if needed (though not applicable in this demo).
    • Element 3:
      • Name: Data Repository
      • Type: Container - Kotlin/Java Classes
      • Description: Abstract data access layer, providing a clean API for data retrieval and manipulation. Acts as a single source of truth for data, mediating between data sources (local database, potentially network in future).
      • Responsibilities: Data abstraction, data caching, managing data sources, enforcing data access policies (if any).
      • Security controls: Data access control within the repository layer, input validation before data persistence, sanitization of data retrieved from data sources.
    • Element 4:
      • Name: Local Database (Room)
      • Type: Container - Android Persistence Library
      • Description: Uses Room persistence library to manage local data storage. Provides an abstraction layer over SQLite database.
      • Responsibilities: Persistent storage of application data (plant information, garden data), data integrity, efficient data access.
      • Security controls: Data encryption at rest (if required, using Android Keystore or SQLCipher, though not implemented in this demo), secure database configuration, protection against SQL injection (Room helps prevent this).
    • Element 5:
      • Name: Android System APIs
      • Type: Container - Android SDK
      • Description: Accesses various Android system features and services through Android SDK APIs (e.g., for camera access, notifications, file storage).
      • Responsibilities: Interacting with device hardware and system services, leveraging platform features.
      • Security controls: Adhering to Android permission model, secure usage of system APIs, handling API responses securely, protecting against API-related vulnerabilities.

DEPLOYMENT

The Sunflower application is deployed to Android devices through standard Android application distribution mechanisms.

flowchart LR
    subgraph "Developer Environment"
        DEV[Developer Workstation]
    end
    subgraph "Google Play Console"
        GPC[Google Play Console]
    end
    subgraph "Google Play Store"
        GPS[Google Play Store]
    end
    subgraph "End User Device"
        AD[Android Device]
        subgraph "Android OS"
            SA[Sunflower Application]
        end
    end

    DEV --> GPC: Upload App Bundle/APK
    GPC --> GPS: Publish and Manage
    GPS --> AD: Download and Install
    AD --> SA: Run Application

    style DEV fill:#f9f,stroke:#333,stroke-width:2px
    style GPC fill:#ccf,stroke:#333,stroke-width:2px
    style GPS fill:#ccf,stroke:#333,stroke-width:2px
    style AD fill:#ccf,stroke:#333,stroke-width:2px
    style SA fill:#fff,stroke:#333,stroke-width:2px
Loading
  • Deployment Diagram Elements:
    • Element 1:
      • Name: Developer Workstation
      • Type: Environment
      • Description: The developer's computer used for writing code, building, and testing the Sunflower application.
      • Responsibilities: Development, building, local testing, signing the application package.
      • Security controls: Secure development practices, code reviews, secure workstation configuration, access control to development tools and code repositories.
    • Element 2:
      • Name: Google Play Console
      • Type: System
      • Description: Web interface for Android developers to manage and publish their applications on the Google Play Store.
      • Responsibilities: Application management, uploading application bundles/APKs, setting up store listings, managing releases, monitoring app performance.
      • Security controls: Google account security (2FA), access control to Play Console, secure communication (HTTPS), Google's platform security measures.
    • Element 3:
      • Name: Google Play Store
      • Type: Environment
      • Description: The official Android app store, distributing the Sunflower application to end-users.
      • Responsibilities: App distribution, app discovery, handling app updates, basic app vetting and malware scanning.
      • Security controls: Google Play Protect, app signing, secure distribution infrastructure, Google's platform security measures.
    • Element 4:
      • Name: Android Device
      • Type: Environment
      • Description: End-user's Android device where the Sunflower application is installed and run.
      • Responsibilities: Running the application, providing runtime environment, user interaction.
      • Security controls: Device security (passcode, biometrics), Android OS security features, application sandboxing, user permissions.
    • Element 5:
      • Name: Sunflower Application (Deployed)
      • Type: Software System Instance
      • Description: Instance of the Sunflower application running on an Android device.
      • Responsibilities: Providing application functionality to the user, local data storage, user interface interaction.
      • Security controls: Android application sandbox, runtime permissions, secure coding practices within the application.

BUILD

The Sunflower application build process is based on Gradle, the standard build system for Android projects.

flowchart LR
    subgraph "Developer Workstation"
        DEV[Developer]
        CODE[Source Code (Git)]
    end
    subgraph "Build System (Local/CI)"
        GRADLE[Gradle Build Tool]
        SDK[Android SDK]
        LINT[Android Lint]
        TEST[Unit & UI Tests]
        SIGN[Signing Keystore]
    end
    subgraph "Build Artifacts"
        APK[APK/App Bundle]
    end

    DEV --> CODE: Code Changes
    CODE --> GRADLE: Source Code Input
    GRADLE --> SDK: Android Libraries & Tools
    GRADLE --> LINT: Static Analysis
    GRADLE --> TEST: Run Tests
    GRADLE --> SIGN: Sign Application
    GRADLE --> APK: Build Output

    style DEV fill:#f9f,stroke:#333,stroke-width:2px
    style CODE fill:#ccf,stroke:#333,stroke-width:2px
    style GRADLE fill:#f9f,stroke:#333,stroke-width:2px
    style SDK fill:#ccf,stroke:#333,stroke-width:2px
    style LINT fill:#ccf,stroke:#333,stroke-width:2px
    style TEST fill:#ccf,stroke:#333,stroke-width:2px
    style SIGN fill:#ccf,stroke:#333,stroke-width:2px
    style APK fill:#f9f,stroke:#333,stroke-width:2px
Loading
  • Build Process Elements:
    • Element 1:
      • Name: Developer
      • Type: Person
      • Description: Software developer writing and modifying the Sunflower application code.
      • Responsibilities: Writing code, committing code changes to version control, running local builds and tests.
      • Security controls: Secure coding practices, code reviews, access control to code repository, secure workstation.
    • Element 2:
      • Name: Source Code (Git)
      • Type: Code Repository
      • Description: Git repository hosting the Sunflower application source code.
      • Responsibilities: Version control, code history, collaboration, source code integrity.
      • Security controls: Access control to repository, branch protection, commit signing, vulnerability scanning of dependencies (if integrated).
    • Element 3:
      • Name: Gradle Build Tool
      • Type: Build Automation Tool
      • Description: Gradle build system used to automate the build process, manage dependencies, compile code, run tests, and package the application.
      • Responsibilities: Build automation, dependency management, compilation, testing, packaging, signing.
      • Security controls: Secure build scripts, dependency vulnerability scanning (using plugins), build environment security, secure handling of signing keys.
    • Element 4:
      • Name: Android SDK
      • Type: Software Development Kit
      • Description: Android Software Development Kit providing libraries, tools, and APIs needed to build Android applications.
      • Responsibilities: Providing build tools, libraries, emulators, and platform APIs.
      • Security controls: Regularly updated SDK to patch vulnerabilities, SDK integrity checks, secure download sources.
    • Element 5:
      • Name: Android Lint
      • Type: Static Analysis Tool
      • Description: Static analysis tool integrated into the Android build process to detect potential code quality and style issues. Can also detect some security vulnerabilities.
      • Responsibilities: Static code analysis, identifying potential issues, enforcing coding standards.
      • Security controls: Configuration of lint rules to include security checks, regular updates to lint tool.
    • Element 6:
      • Name: Unit & UI Tests
      • Type: Automated Tests
      • Description: Automated unit and UI tests to verify application functionality and catch regressions.
      • Responsibilities: Ensuring code quality, detecting bugs, verifying functionality.
      • Security controls: Security-focused test cases (e.g., input validation tests), secure test data management.
    • Element 7:
      • Name: Signing Keystore
      • Type: Digital Certificate Store
      • Description: Keystore containing the private key used to digitally sign the Android application package.
      • Responsibilities: Application signing for integrity and authenticity, secure storage of private key.
      • Security controls: Strong password protection for keystore, secure storage of keystore file (e.g., hardware security module, secure vault), access control to keystore.
    • Element 8:
      • Name: APK/App Bundle
      • Type: Build Artifact
      • Description: The final Android application package (APK or App Bundle) ready for deployment.
      • Responsibilities: Deployable application package, containing compiled code, resources, and assets.
      • Security controls: Digitally signed package, integrity protection through signing, potential for further security scanning of the artifact before deployment.

RISK ASSESSMENT

  • Critical Business Processes:

    • Providing a functional and educational example of modern Android development.
    • Maintaining the integrity and quality of the example code.
    • Ensuring the example does not inadvertently introduce insecure coding practices to developers.

  • Data to Protect and Sensitivity:

    • Plant data: Publicly available information about plants. Low sensitivity.
    • User garden data (plantings, notes): Personal user data related to their virtual garden. Low to medium sensitivity. While not highly sensitive, user data should be treated with respect and protected from unauthorized access or modification within the application's scope.

QUESTIONS & ASSUMPTIONS

  • Questions:

    • Is there any plan to extend Sunflower to include network features or user accounts in the future? If so, security requirements will significantly increase.
    • What is the intended audience skill level? This will influence the level of detail and security considerations needed in the example.
    • Are there any specific compliance requirements or security standards that this project should adhere to, even as a demo application?

  • Assumptions:

    • The primary goal is educational, not to build a production-ready, feature-rich application.
    • Security is considered primarily from the perspective of demonstrating good Android development practices, rather than implementing advanced security features.
    • The application is intended for single-user, offline use in its current form.
    • Data stored by the application is considered low to medium sensitivity and does not require enterprise-grade security measures in this demo context.