People, Networks, and Identity are three crucial areas of security.
Recent articles about large corporations exposing millions of customers’ data have been in the news lately. The fascinating forensics from some of the breaches was a determination that a contractor working remotely was hacked and exposed a tremendous amount of data that ended up on the dark web.
I find myself wondering what sort of protections these companies and their contractors put in place to protect the company’s intellectual property and, more importantly, the company’s customer data.
I keep my remote work environment separate from home computers. I keep social media, email, and personal information away from the work environment. My home office is set up on a separate network! The reason is simple if the company becomes compromised, the compromise will not affect my family. Conversely, suppose anyone in my family gets hacked, and a hacker breaches our home network. In that case, I have at least separated the company network to reduce the possibility that the hack will not impact the company.
I keep my smart TVs, smart speakers, and home appliances on a separate network, not just because it protects the company network but also because it makes sense to keep smart devices on a separate network. This article will cover how to design separate office and home networks as remote worker.
Let’s start with the Internet connection. I prefer a firewall that can provide at least three separate networks. A network that becomes the wireless network for my family and my personal computers, another network for my work, and another network for smart appliances. Additionally, I have a DMZ network to potentially expose applications from my Kubernetes cluster or my vSphere server.
My remote office uses one firewall and one wireless router to separate networks.
We have personal computers for each member of my family connected to the family network. I have a WiFi router providing access from the family network to our phones, laptops, printers, and computers.
The WiFi router also has the option to allow guests. Many routers support a feature called guest networking, which creates a separate Wi-Fi network for friends and family to use when they visit. They can access the internet from the guest network, but they can’t access network resources like shared folders, printers, or NAS devices. All smart devices (TVs, smart speakers, light controllers, smart thermostats, Ring doorbells) are set up on the guest network such that they do not have access to our family computers.
The firewall is set up to provide two more networks, a DMZ and an Office Network. The Work laptop is connected to the Office network and thus separated from the family network and the smart devices. Additionally, the work laptop has a VPN into the corporate network to secure its connection across the internet. I do allow the work laptop access to the family printers by setting a rule only to allow print jobs but no connectivity to family computers.
I have a refurbished Dell server that is set up with VMWare vSphere. There was a sale to get a refurbished Dell server with 192 GBytes of Memory and 2 Xeon processors, and no disks that I found on eBay for $250. I stuck a couple of 1 Terabyte SSD drives into it, and the refurbished server does a fantastic job running as a vSphere server in the lab!
Additionally, I have five refurbished Dell mini-tower computers from eBay, each cheaper than purchasing several Rasberry Pi mini-computers. The refurbished Dell desktops have far more memory and computing power than a Rasberry Pi. Four of the desktops are used as a Kubernetes cluster, and the fifth computer is used for backups.
The vSphere server and the Kubernetes cluster are placed into the DMZ network. This allows me to expose application development to the internet with less chance of a compromise impacting the home or office networks.
When considering purchasing a new system for a business, there are good questions to ask about the new system:
What is the yearly capital expense and operating costs?
What and when is the return on investment?
Does the system have the capability to meet our requirements?
How will the new system integrate into our business?
What impact will the new system have on our business:
Do we have the capacity to support a new system?
Support, engineering, maintenance, backups, storage, etc.
How will the new system impact other systems?
Will it require training
Have we reviewed and considered competitive products?
Can we evaluate the product before purchase?
Should we assess other products before the decision to purchase?
Standard practice
How do we answer these questions before investing in a new product. My answer is that we create a conceptual architecture, create a cost model, and perform a product evaluation before purchase. No matter the size of a business, it is probably a good idea to evaluate a product before delivering a new system into the business. It is my recommendation to have standard practice that will answer the above questions, test and evaluate new products before purchasing a new system. Standard practice prevents mishaps, misconfigurations and increases efficiency of delivery and utilization of new systems.
More about standards
At some point in our history of IT, Enterprising managers realized the need to create business standards. So they got together to develop and establish best practices like ISO 9001, CMM, CMMI, ITIL, and ITSM. Architects also realized a need to create common architecture frameworks, for example, Open Group Architectural Framework, Zachman Framework, Federal Enterprise Architectural Framework, and TOGAF.
There is a naïve thinking that just by being agile, an architecture will gradually emerge, out of bi-weekly refactorings. This belief was amplified by a rather poorly worded principle #11 in the agile manifesto, which states that:
“The best architectures, requirements, and designs emerge from self-organizing teams.”
and cemented by profuse amount of repeated mantras like: YAGNI (You Ain’t Gonna Need It) or No BUFD (No Big Up-Front Design), or “Defer decision to the last responsible moment”. (This principle is neither prescriptive, not can it be tested, as Séguin et al. showed in […], so it is probably not a principle, but merely an observation or a wish.)
I personally agree that it is naive to believe architecture, requirements and design eventually emerge from teams! Seriously, read the link provided about architecture technical debt. Perhaps you’ll agree that it would be a good practice to include architectural review on a regular basis alongside of today’s agile teams.
Another good article to read, can be found at scaledagileframework.com. Today there is a constant appetite for DevOps and an Agile framework of managing deployments. Scaled agile Framework recommends providing additional practices into agile planning. We shouldn’t be so quick to thinking design is an eventual outcome of agile development and that we need to have regular business and architectural reviews during product development. Please read this article: Architecting really big IT and cyber-physical systems?
Understanding basic concepts of architecture, is the reason I’m writing this article. Please see the diagram below that is my method to represent the architecture stages of a new system that will incorporate a commercial of the shelf system (COTS) using a waterfall approach. Development and design using Agile development processes will have a different architectural approach and will be discussed in another Blog post.
A small business might have less stringent requirements regarding the architectural process. It might combine the stages depicted in the diagram below into smaller iterations of documentation but will still reap benefits by establishing a standard practice.
Architecture practice for commercial products may also need to consider other architecture disciplines. For example, if a large global corporation has many business systems in different regions, management of distributed systems requires service architecture and management overview of the many systems. Architects could produce a service architecture by defining the relationship and integration of COTS products as services. Placing the systems into categories, methods of integration, dependencies, and other service-oriented documents.
Business Plan Goals, objectives, requirements, business process, Workflows
Conceptual Architecture System constructs, relationships, organization, strategy
Proof of Concept Review products, down select products, Test products & test results
Logical Architecture Capabilities, Logical constructs, logical diagrams, service levels, Abilities
Operations Deployment model and installation guides
Reviews Scheduled reviews of capacity performance and architectural design
The business plan
Most new systems are born from a business goal, a functional requirement, or a need for business improvement. A business plan most often arises during a conversation. Sometimes in the elevator or by email. Perhaps a discussion at the water cooler. Concepts occur in a meeting or on the back of a napkin. No matter how a concept is born, someone takes the reign and runs with the idea.
Almost always, the questions become:
*What will it cost? *What is my return? *When can the objective or goal be achieved? *How does this impact the business? Why can’t I have this in place tomorrow?
Conceptual Architecture
Conceptual Architecture to the rescue.
The primary purpose of conceptual architecture is to convey the concepts of a new system or systems in a non-technical manner, and present the architecture with business acumen instead of technical jargon. Conceptual Architecture is a method for stakeholders to understand and agree to new business systems.
Joseph O’Mara
Concept architecture is a business-minded perception of goals and objectives. Ideally, concept architecture is not technical and does not come to conclusions on a product or solution. Instead, concept architecture brings together an agreement of the goals, objectives & requirements, primarily to agree conceptually what will become a new business system.
Instead of architecture on the back of a napkin, an architect gathers the requirements and presents the conceptualization to stakeholders so that everyone can agree; YES, that is what we want to accomplish.
A small business IT manager might put together a few diagrams, some assumptions, the understanding of requirements, and perform a quick presentation to agree on the new system conceptually.
Larger businesses most likely will have a template for conceptual architecture. A Conceptual Architecture template will assure critical elements of architecture considerations are captured and agreed amongst stakeholders.
A conceptual architecture template would convey the essential aspects of a new system by presenting:
conceptual diagrams
business purpose, goals & requirements
objectives and potentially phases to achieve objectives
Location: On-premise, Hybrid, Cloud environment, regions, data centers
Service views: What is the new system & its intended relationship to other services
System Integrations
Potentially where it fits into business processes or workflows
How will the new system consume or produce, and secure data or knowledge property
Proof of Concept
Proof of Concept provides the ability to get past the hype. Most products provide market hype (i.e. This product will save money, while solving world peace). Proof of Concept brings the product into a lab, performs tests against requirements and measures its capabilities. Does the product actually achieve the marketed hype? More importantly, does the product meet our requirements?
Joseph O’Mara
Once concept architecture has agreement amongst stakeholders, we move to a phase where IT reviews the potential new system and its ability to meet requirements. Reviewing requirements and capabilities sometimes require the creation of a capability matrix. Perhaps a cost model is produced as well. If reviewing several products as candidates for use as the new system, costs and capabilities will be matrixed to compare products. A capability matrix and cost model enable IT to choose which product to evaluate by estimating the competitive product’s cost and abilities. It is not uncommon to work with a salesperson, pre-sales engineers, and pre-sales architects to understand how a product will meet desired capabilities—and what is involved in deploying and supporting the new system, including an estimate of the cost to maintain and deploy.
Once finishing a paper review of potential products for the new system, an evaluation is in order. By selecting one or two products to evaluate, we then move into an evaluation phase. We coordinate with the vendor(s) a trial license and assess the product in a test environment..
It is not uncommon to have a simple logical and technical design prepared for a test environment, making sure to approximate our plan to implement in production as best as possible.
The next step is a test plan. An evaluation should include other systems that simulate production. Especially if any integrations & dependencies are required as part of the solution. Additionally, have the support and maintenance aspects of production included in the plan. The plan should include dependencies like security integration, database integration, and data feeds. The test plan should consist of users and administrators and any other roles that might be necessary for testing. Including actual users, administrators, and managers into the test program most often can work out the kinks in a new system before deployment. Potentially finding a break/fix element of the product that forces a decision not to purchase that product for your business. Or potentially finding aspects of cost not considered.
Once the testing is complete, the cost model, the capabilities matrix, the test plan, and test results are delivered to stakeholders to reach an agreement. They will decide if it makes sense to continue with implementing the new system. Most importantly, everyone agrees conceptually to invest in a new product for the business.
Logical Architecture
Once everyone agrees conceptually to a new product, its cost estimates, and expected objectives, it’s time to figure out how the new product will fit into production. Sometimes the move into production is simple, and sometimes it can be complicated as the new system may need to integrate with other systems. An architect works out how a system integrates or operates alongside other business systems.
A logical architecture usually represents a singular system architecture. A solution architecture is created when multiple systems each representing a different service are being introduced into a business. Service architecture represents service integration, concentrating on services, interfaces, data flow, and other considerations. Service architecture typically describes a system as a service that is part of a discipline. For example, Active Directory is an identity and authorization service that is a part of a Security Discipline.
Logical architecture is an abstract method of representing new systems. The different architectures (logical, solution, or service) create “Abstract” constructs.
For example;
Logical diagrams, functional diagrams, service diagrams but not physical diagrams
Description of the system, its purpose and functionality
Perhaps including modules of the system if it’s logically important to understand module location and function (i.e. database vs front end web server)
location geographically or data centers or different corporate buildings, or perhaps even global regions, but not the physical location within a business (i.e., in a closet or a specific area of the building)
Who is using a new product, like finance or manufacturing
Roles if necessary, IT management vs. user roles
Network: internet-facing product will be in a DMZ, but not the technical details of that DMZ
Backup method and schedule (logically) without the technical details
Maintenance windows and SLA statements without the actual maintenance plans
A logical architecture will also construct the “ABILITIES”. What is meant by “Abilities”? “Abilities” is the operational considerations of managing, maintaining and servicing technology.
Abilities
Capability
Reliability
Scalability
Recoverability
Maintainability
Measurability
Expandability
Logical, solution, or service architecture will not only stipulate the “Abilities” of the new system, but also strive to construct a level of service acceptable to the business by defining service level agreements (SLA) and how the architecture will achieve the SLA
Technical Architecture
Technical (or physical) architecture is a little dubious these days, as automation and virtualization have reduced the need to understand the physical installation of new products. At one time, introducing a new system into a data center took much consideration. Things like power consumption, rack space, network wiring, network design, connections to storage, and backups were all considerations for installing a new system physically. Data Centers still need to worry about power, racks, wiring, storage, and networks but are usually considered private or public cloud infrastructure considerations.
Technical architecture in a business with a hypervisor farm will document the technological constructs of virtualization and its sizing of a virtual server(s). Details such as network rules, load balancing rules, roles and responsibilities, maintenance plans, backup plans are part of technical architecture. Technical architecture is where the rubber meets the road, so to say!
Technical architecture documentation is less about the power, wires, and racks with automated infrastructure and more about the coding and parameters of infrastructure with automated infrastructure tools such as VMware SaltStack, AWS Cloudformation, Google Cloud Deployment Manager, and Azure Resource Manager as examples of infrastructure automation. Another infrastructure provisioning tool is Hashicorp Terraform, which does a great job creating code to provision VMWare, AWS, Google, and Azure platforms. These tools are considered Infrastructure as Code, and many consider this a great way of documenting the technical architecture because Infrastructure as Code itself can be archived and is itself a document of the provisioned system(s).
