Adding pre-reqs part 2

This commit is contained in:
2023-12-26 15:54:39 -05:00
parent b22b58c935
commit 38a1bd6b32
2 changed files with 47 additions and 1 deletions

View File

@@ -6,7 +6,7 @@ draft: false
# Introduction
Prerequisites are incredibly important to any development project and was the (OWASP Top 10, Number 4, Insecure Design)[https://owasp.org/Top10/A04_2021-Insecure_Design/]. For the purpose of this document we will talk about it in context of *security implications*.
Prerequisites are incredibly important to any development project and was the [OWASP Top 10, Number 4, Insecure Design](https://owasp.org/Top10/A04_2021-Insecure_Design/). For the purpose of this document we will talk about it in context of *security implications*.
# Planning Comes First

View File

@@ -0,0 +1,46 @@
---
title: "Pre-Requisites (Part II) Initial Design: Code Complete Summations"
date: 2023-12-26
draft: true
---
# Introduction
Prerequisites are incredibly important to any development project and was the [OWASP Top 10, Number 4, Insecure Design](https://owasp.org/Top10/A04_2021-Insecure_Design/). For the purpose of this document we will talk about it in context of *security implications*.
This ended up being too big of a topic for just one post, so here is part 2. In {{< ref "code-complete-summations-pre-requisets-part-1.md" >}}, we looked at why pre-reqs are needed in general and how they apply to types of projects. In part 2 we'll look at architectural pre-reqs.
# Planning Comes First
As the saying goes a failure to plan is a plan to fail. Without a solid foundation, similar to building a house, the entire program can fall. With no plan in place, code can end up being added in a half-hazard way, causing code paths to become unknown or unintentionally created. These code paths then become more difficult to maintain.
Another saying that can apply is an ounce of preparation is worth a pound of cure. This can become even more poignant in software development, from a security perspective. From just a development perspective, this could mean saving time later trying to rewrite code that no longer fits or trying to shoehorn in code that doesn't quite fit. For security this can become a major issue if large security flaws are found in the software.
# Why Architectural Prerequisites
General pre-reqs need to be generic enough that the customer and users will be able to understand what is required. Architectural requirements are for the developers themselves. This is hugely important as it keeps the code base consistent and easy to maintain. From a security perspective this is vital as the less chaos in the code the less mistakes there will be. Also, by making it more maintainable, if bugs or security flaws are found, it will require less time and effort to fix.
By having a solid architectural foundation, this will allow the developers to break up work where appropriate. See [Data Design](#data-design) for more detail.
# Architectural Features
Architectural designs can be broken down into multiple pieces, each with their own considerations.
## Communication
How will this software communicate between components in the project and external to the project, both protocol and data structure.
Protocols are vital here as they will help determine how secure communications between programs or across networks will be. You'll want to pick something that either has encryption by default or can be easily added. Authentication is also a must. Some protocols or services have built in authentication methods, while others will need to be worked into the initial connection. These things need to be thought about ahead of time before diving in.
The data structure is very important as well since all components need to agree on what to look for. See
## Major Classes
## Data Design
## User Interface
## Error Processing and Logging
# Conclusion