Security Architecture provides a means for engineers to maintain consistency and traceability in security design. Just as a plot of land is charted, a foundation is laid, and framing constructed for a physical building, similar milestones occur in the world of cyber security architecture.
A security architecture plan based on the SABSA model
How the SABSA risk assessment method is applied
Logical Layer: Mapping
A network diagram for the logical layer
Component Layer: Security tool matching
Matching type of security product to business needs
The SABSA method provides a clear cut path from long-term strategy to implementing operational details by using its 7-layer model. By utilizing the steps in the 36-cell Matrix, we can clearly see how every preceding step trickles down to make a more detailed framework to maintain alignment with solutions for business risk, processes, geography, time dependencies, and future decision making.
As described on SABSA's website:
"SABSA is a proven methodology for developing business-driven, risk and opportunity focused Security Architectures at both enterprise and solutions level that traceable support business objectives. It is also widely used for Information Assurance Architectures, Risk Management Frameworks, and to align and seamlessly integrate security and risk management into IT Architecture methods and frameworks.SABSA is comprised of a series of integrated frameworks, models, methods and processes, used independently or as an holistic integrated enterprise solution, including:
Business Requirements Engineering Framework (known as Attributes Profiling)
Risk and Opportunity Management Framework
Policy Architecture Framework
Security Services-Oriented Architecture Framework
Security Domain Framework
Through-life Security Service Management & Performance Management Framework (sabsa.org)"
The Seven Layers of the SABSA Architecture (Image from Vanharen.Net):
Infamous American Designer of the 1940’s Charles Eames said, “Recognizing the need is the primary condition for design” (Eames, n.d.). For a security architect, the quote is applicable, as the needs of the business and identifying key motivations are recognized first. The enterprise builder may use the SABSA model. The model divides the architectural building process into six layers and asks six questions on each layer: what, why, how, who, where, and when. In this discussion, an audit layer is added to make it an all-inclusive seven-layer model (as recommended in our reading). Each layer is dependent on the plans of the preceding layer until built, where it will ultimately be managed and inspected. Below, I present a description of the layers, the six W’s on each layer, and how the layers are interconnected.
Contextual Layer (Business View)
The owner of an enterprise makes the decision to start and budget for a security plan. To develop the plan, the owner can answer six key question. The owner starts by asking, what kind of architecture is needed (e.g. industry specific, customer centric), how it will be used (e.g. specific business processes, accounting, supply chain), why they need this system (e.g. pass audits and inspections, secure bank accounts, secure ePHI), who will use the security system(s) (e.g. number of users online, risk levels of remote workers), where the security system is implemented (e.g. departments, region, country), and when the system is used (e.g. time during day, week, year, and concentration/usage over time). After the owner, or executive, comprehends the business needs through these six questions, the enterprise is ready to contract an Architect to develop a realizable security plan.
Conceptual Layer (Architect’s View)
The Architect takes the ideas from the owner, and matures the overall concept by which the business requirements of the enterprise may be met (Sherwood at al., 2005). Additionally, the Architect defines the fundamental concepts that guide the selection and organization of the logical and physical elements of the lower layers of abstraction. The contextual layer defines what business attributes to protect (e.g. user attributes, legal and regulatory attributes), why the protections are important (e.g. business risks by priority), how to achieve those protections (e.g. cryptographic infrastructure strategy and/or role-based models), who is involved in security management (e.g. security team relationships, inter-domain trust relationships), where you want to achieve protection in terms of security domains (e.g. logical – PKI structure, physical – CISCO LAN subnets), and when is the protection relevant (e.g. expiration of keys, certificates, passwords, sessions, time-stamping functions). Once these items are realized and documented by the Architect, it is up to the designer to create a meaningful logical framework.
Logical Layer (Designer’s View)
When the designer takes over from the Architect, the designer transforms the Architect’s plans into a logical structure to enable physical engineering of the plan. The designer is concerned with what business information presents a logical representation of the business (e.g. graphing protocols for trusted third parties), why the security policy is in place and its requirements (e.g. certificate authority and physical domain policies), how the logical security services fit together into a complex system and meets operational requirements (e.g. system assurance, integrity protections, entity authentication), who uses the specified security framework to create a schema showing attributes and privileged roles (e.g. users, admins, auditors), where specifically in the security domain and/or inter-domain relationship (e.g. logical or physical security domains), and when the security process is implemented (e.g. registration, login, session management). When the designer’s plan is finished and can answer all six questions, the work is handed over the builder who can turn logical drawings into a real composition.
Physical Layer (Builder’s View)
The builder is tasked to build the physical security infrastructure involving tangible components that meet the requirements of the designer’s plan. The logical plan is translated into hardware, software, and supporting infrastructure technology to be placed on site. The builder focuses on what business data models and security-related data structures to build upon (e.g. tables, messages, pointers, certificates), why the structures are in place and identifying rules driving logical decision-making (e.g. conditions, best practices, procedures), how security mechanisms will be hosted (e.g. encryption systems, virus protection software at end-user devices), who will be dependent on the security system and their interactions with the system (e.g. users acceptance of screen formats, administrations ability to configure security), where exactly the security system is placed (e.g. location of physical layout of hardware, software, and communication lines), and when the control structures are executed (e.g. sequences, events, lifetimes, and intervals). During the building stage of forming physical systems, the builder will pull the expertise from various experts (the tradesman) to materialize the plan further.
Component Layer (Tradesman’s View)
At the component layer, the tradesman is utilized to carry out the builder’s plan. The tradesman are product specialists in hardware, software, or other services. These specialists are concerned with what the data structure specifications ask for, why they are in place and influencing forces in the system’s structure, how those products and tools fit the proposed system, who uses the secure system and control systems in place (e.g. users, admins, and access control lists), where the computer processes occur or node-addresses are used, and when crucial steps are initiated (e.g. timing of process, sequencing of key events). After the work is done by the builder and tradesman, it is now the turn of the manager to run the security system throughout its operational lifetime.
Operational Security Architecture Layer (Manager’s View)
The system is now built and ready to be run by an individual with knowledge of the security system(s) in place. The manager’s job is to establish what processes ensure operational continuity in terms of maintaining security of data and information (i.e. keeping confidentiality, integrity, availability, auditability, and accountability), why the processes are important (i.e. to minimize failure or disruptions of certain programs or processes), how to perform the security-related operations (e.g. administration of software, locations of backups, emergency response procedures), who provides support to the security system (e.g. responsibility hierarchy), where to maintain security of the manager’s domain (e.g. the site, network layout, and platform), and when to schedule and execute security-related operations. When these questions are answered, the security system is operational, but may not be auditable. This creates a seventh supporting layer to the SABSA model.
Audit Layer (Inspector’s View) – Added to the SABSA Model
The inspector is concerned that the security architecture is “complete, consistent, robust and fit-for-purpose in every way” (Sherwood et al., 2005). The inspector can be internal or external auditors, or the systems quality assurance personnel. The inspector will look for what establishes a secure or vulnerable system (e.g. identification of critical systems and their respective controls), why the system is secure or vulnerable (e.g. weak password policy, strong physical controls), understanding how the users perform the controls on the system (e.g. HR hiring process, administration of public keys), who has access to change or alter those controls (e.g. managers wearing multiple hats), where the security controls are located on the network or software, and when those controls are tested during the year or executed on a daily basis. These questions related to the inspector’s view are not recognized by the SABSA model since the correct implementation of the six layers will enable successful audits when answering the “who” question on each layer.
The six SABSA layers, and the added audit layer, combine to create an intelligent seven-layer scheme to develop a security architecture. With each team on every layer answering the six questions relating to what, why, how, who, where, and when, will provide clear direction for the personnel and timely construction to meet deadlines. As mentioned, if the six-layer model is done correctly, there is a high level of assurance for the security system in place and little attention toward the audit layer (with respect to adequate vulnerability testing of the system). The flow of information starts vague in the contextual layer to highly specified in the component layer. Therefore, the speed of completion and accuracy of subsequent layers are dependent on the accuracy of the preceding layer. Importance should be placed on how plans, designs, and instructions are communicated with the development team and external parties.
The security architecture should be kept secret and too daunting for attackers to figure out. This quote by an American Architect Louis I. Kahn, creator of monumental buildings, directly applies to security architecture: “A great building must begin with the unmeasurable, must go through measurable means when it is being designed and in the end must be unmeasurable” (Kahn, n.d.).
Ernst & Young. (2012, April 26). Enterprise Security Architecture: Business-Driven Security [Power Point Slides]. Retrieved from http://www.isaca.org/chapters5/Ireland/Documents/2012%20Presentations/Enterprise%20Security%20 Architecture%20-%20Business%20Driven%20Security.pdfSabsa.org (n.d.)
The SABSA Institute. Retrieved August 20, 2018 from https://sabsa.org/the-sabsa-institute/
After stakeholders are interviewed, the SABSA process begins with the contextual layer and the Risk Assessment Method. First, business drivers are matched to business attributes. The business attribute list can be used as a starting point to list business drivers or a check list to make sure all business requirements are covered in the cyber architecture. These drivers are matched to the corresponding threat against the driver and assigned an impact level: High, Medium, and Low. The matrix continues to real world vulnerabilities and the associated risk category.
The formation of the SABSA Matrices provides are driven by many design principles:
1. Business Driven: Security that contributes to business success.
2. Risk Driven: Security layers appropriate to business risk.
3. Value Driven: Security to protect and promote the creation of new business value.
4. Process Driven: Security to address time horizons and lifecycles.
5. Layered Traceability: A layered model with each layer inheriting security requirements for traceability.
6. Completeness: Traceability through the matrices from the highest level to the lower levels.
7. Justification: All details on the lower layers are traces to a higher layer in the matrix.
8. Architecture Design Artifacts: SABSA defines documented artifacts to be produced in the matrix.
9. Management Activities: Activities which artifacts are produced and how they are applied to business operations.
Pre-Contextual Layer: The Stakeholder View
The table below from SABSA's website provides the different views by Chief Officers due to their business roles and responsibilities. This table can be used to provide direction to each stakeholder on how SABSA Security Architecture works in their favor.
ReferenceSabsa.org. (2018, August). R101 – SABSA Matrices 2018 Release Notes. Retrieved from https://sabsa.org/sabsa-matrices-2018-download-request/
Conceptual Layer & Life Form Analogy
In our Enterprise Security Architecture book by Sherwood, Clark, and Lynas, it describes the conceptual layer as “able to design the forest rather the trees”. Meaning, the architect is concerned with the overall shape and size of the forest, tree locations, density, and overall mix of tree species.
If I was to provide my own analogy, it would be the concept of a life-forms to inhabit an ecological area. The questions to be asked at the architectural layer would sound like: What would that life form need in order to survive and carry out its duties? What is the atmosphere composed of? will it be oxygen based? What temperatures would the lifeforms need to endure? Extreme-hot or extreme-cold? What physical traits will it need to survive threats of the environment? What level of processing power will the brain of the lifeforms need to carry out its objectives and resolve issues to changing environment conditions?
The strategies and security layering set forth by the architect trickle down to the remaining SABSA ® layers. To continue with the life-form analogy, after the architect developed an overall model of the life form based on environmental requirements, security layers (e.g. immune system, skeletal structure, organ locations, psychological processes), and strategy (e.g. exoskeleton v. endoskeleton or water based v. land based), the logical layer would consist of how the life form communicate with other life form (e.g. verbal v. non-verbal communication), diet considerations (e.g. meat v. vegetable digestion, carb and protein ratios), learning speeds, cellular adaptation, and psychological cycles and barriers to avoid harmful reprogramming by other lifeforms.
Then, the physical layer would be the actual construction of the life form. Developing the DNA structure (updated data model) that will grow into the body type, organs, and nervous system specified in the preceding layers. Security mechanisms matched to security services (immune system, blood vessel counts, brain components that manage other services). Addressing language compatibility concerns with variations of other evolved species from the same DNA set.
The component layer would be involved with specifics of the life form for survival. How many teeth, and how sharp will they be? And how much mirror neurons to allocate to the brain to ensure learning and continuation of the species. They would be concerned with a detailed neural network and how to prevent those mechanisms from being overridden with “neural malware”. The component layer would also be concerned with memory, how those markers are created in the brain, accessed, and to protect against malicious programming.
Sabsa.org. (2018, August). R101 – SABSA Matrices 2018 Release Notes. Retrieved from https://sabsa.org/sabsa-matrices-2018-download-request/
Questions to Ask in the Logical Layer
The logical layer is mainly concerned with defining a comprehensive set of functional requirements. These functional requirements for the business may require one of the many logical security architectures shown below to keep that system secure:
Certificate Management Architecture
Directory Service Architecture
Access Control Architecture
Entity Authentication Architecture
Service Management Architecture
Incident Response Architecture
This stage does not include specific security mechanisms that will be used to deliver those functions (that is for the next layer).
What is a Security Authority?
A security authority is an entity that implements the security policy on behalf of the owner. They are effectively the custodian of the given security domain by the owner. One such tool used is the Local Security Authority (LSA) in Microsoft’s Security Subsystem Architecture. The LSA carries out the following:
-The domains that are trusted to authenticate logon attempts.
-Who can have access to the system and in what way (for example, interactively, over the network, or as a service).
-Who is assigned privileges.
-What security auditing is to be performed.
-Default memory quotas (paged and non-paged memory pool usage).
What are six common security services?
The six common security services are the following:
1) Prevention Services (e.g. Device authentication)
2) Containment Services (e.g. Stored data confidentiality, Security training & awareness)
3) Detection and Notification Services (e.g. message integrity protection, security monitoring)
4) Event Collection and Event Tracking Services (e.g. audit trails, security operations management)
5 )Recovery and Restoration Services (e.g. Incident response, software replication, and backup)
6) Assurance Services (e.g. Audit trails, security audit, security monitoring, security measurement and metrics)
*It’s noted that security service #6 is similar to #4 with the exception of one sub-service that emphasizes security auditing over security management.
What are the three types of Access Control Services?
The three types of access controls are for the physical domain (e.g. building and production environment), logical domains (e.g. applications, files, databases), and physical access to hardware platforms and networks using logical access control (e.g. permission and software decision-making functions).
Why is the concept of Trusted Time so important in distributed systems?
Trusted time is used as a universally agreed value to secure communication (i.e. Protocols) between multiple systems. The time stamp used in a protocol helps prevent message delay, message replay or message re-sequencing by an unauthorized eavesdropper. The time stamp is protected by cryptographic mechanisms. If the time is tampered with by an opponent, they will allow the receiver to accept a message that is “out of time”.
What are the logical steps required for an appropriate incident response according to the textbook?
The logical steps to incident response are the following:
-Data Normalization and Collation
-Incident Assessment and Conclusions
-Response Action Management
What are the benefits of creating an Entity Schema?
The benefits of creating an entity schema include maintaining the integrity and quality of the data stored in the directory. Second, a directory schema reduces duplication of data (polyinstantiation). Third, the schema imposes constraints on the size, range and format of data objects stores in the directory. Fourth, it provides a well-documented and predicable method for directory-enabled applications and services to access and modify the collection of directory objects. Fifth, the schema helps slow down the effects of directory entropy, in which over a period with constant use by many entities, “the contents of the directory tend to move towards chaos”.
What are the six of the main (common) role types?
The six main role types under a schema are:
1) User roles
2) Business Manager Roles
3) System manager Roles
4) Operations Management Roles
5) Administrator Roles
6) Auditor Roles
What four elements comprise the Security Services Management Domain?
The four elements that comprise the Security Services Management Domain are the following:
1)Managed Security Objects and their Management Agents
2) Security Management Information Database
3) Security Service Management Functions (within security application)
4) The security management personnel
What are the six activities addressed in the Security Processing Cycle?
The six activities of the Security Processing Cycle are:
1) Introducing and registering new organization entities
2) Introducing and registering new users
3) Setting up authorized privileges
4) Registration renewal
5) Certificate issue and renewal
6) Provisioning and configuring equipment throughout the environment
The physical layer is considered the brick and mortar stage of the architecture. The IT teams review various network boxes, how many required, where they will be located, size and performance, and bandwidth needed. Second, physical data structure are used to realize logical information structures and physical security mechanisms are used to implement logical security services.
What is entropy in terms of passphrase complexity?
Entropy is a measure of randomness contained in the data. The more random the data (e.g. key strokes speed, mouse movement, clock) the higher the entropy used. The randomness is used to create private key. This makes it less predictable for an attacker to guess the data contained in the key. The goal is to have low redundancy of data inputs to make the key to create high entropy.
What is file locking in database security?
File locking in database security refers to locking a file when a user is accessing the file to prevent data from being corrupted by conflicting changes by concurrent users in the database. Without file locking, transactions spanning from different sessions, users, and departments can create corruption of data.
What is the difference between a User, a Database Administrator, and a Systems Administrator?
The three objects refer to the three classes of users in a SQL database. The “User” has access privileges as defined in the RBAC component by the Database Administrator. The “Database Administrator” has access to configuring users and their privileges using a RBAC, setting access controls, and establishing security, form, data input, and network settings of the database. The “System Administrator” has access to and controls all databases in the entire DBMS. The “System Administrator” usually has exclusive access to the database server and applications that change the DBMS using a password that is different from the database administrator.
What is the difference between security practices and security procedures?
The difference between security practices and security procedures is the security practices describe behaviors, while security procedures provide step-by-step instructions. The security practices term is synonymous with “good practices” or “best practice” which entail the method generally works in other environments. Security procedures are documented step-by-step instructions on how specific tasks are to be performed.
For example, it’s a security practice to have daily backups of a database to an off-site location. This is more important nowadays given how ransomware or disaster-prone areas (e.g. hurricanes, earthquakes, floods) can affect the network on-site. The security procedure would involve how to effectively implement those backups mechanisms and to ensure data integrity (e.g. no errors during copy) on a step-by-step basis.
What are the four fundamental security services that can be implemented using cryptography?
The four fundamental security services that can be implemented with cryptography are:
1) Confidentiality: keeping data private (given technology contraints). Advisable to store data with latest encryption standards to prevent computing power from decrypting information in the near future.
2) Integrity: protecting alteration of information by having detection mechanisms (e.g. time stamp).
3) Authenticity: proving that information originated from an authenticated trusted source (e.g. digital certificate).
4) Non-repudiation: Prevent a dishonest party from later denying (repudiating) the authenticity of information provided by that party.
The four services are dependent on the strength of the key management system.
What is the difference between a secret key, a public key and a private key?
A secret key is used in symmetric cryptosystem where a the secret key is used to turn ciphertext into plaint text. I believe this can be a concept or an actual text string. A quick example would be a secret key of the “alphabet letter minus 1”.
“Hello World” is turned into “GDKKN VNQKC”
A BC DE FG HI JK LM NO PQ RS TU VW XYZ
Z AB CD EF GH IJ KL MN OP QR ST UV WXY
The public key and private key pairs are used in to create asymmetric cryptosystems. The private key is generated from a high entropy source and stored securely on the sender’s machine. The sender creates and signs a public key with the private key “claiming to be the owner of the public key”. This public key is then forwarded to the recipient to be used to encrypt data in a message to be returned to the sender. The messages are decrypted with private keys and the messages are to the sender are encrypted with public keys to keep separation of keys that are used for authorization and authentication.
What must a super-user account never be used for and why?
As it relates to good practice for the production environment, the super-user account must not be used for routine operations. Given the privileges of a super-user account, the ability for error or compromise of the database increases as the super-user account is used over time. Privilege escalation is one of the processes used by an attacker, therefore an intruder on the network will be scraping for any super-user accounts to gain more control.
System handling tips presented in the security architecture book are as follows:
-All routine operations should be fully analyzed to define what accesses are required to fulfill the job
-Captive script or programs should be constructed that run with super-user privilege where needed, without granting full super-user status to the person naming the utility. Every single routine operation task should be subject to this treatment.
-The platform can then be managed for day-to-day operations without the super-user account ever being required
-The super-user account should be protected by a secret password that is written down and locked in a safe under the control of the senior manager who does not personally have any hands-on computer operations duties.
-Senior manager makes the decision of releasing the super user password in emergency situations
-If “so-called” emergencies occur on a regular basis, new utilities with separate passwords should be formed to prevent the reuse of super-user accounts
-Once a super-user password is used, it should be changed and stored in the safe.
-Password setting should be the responsibility of a security administration team that has no responsibility for computer operations.
What are the key issues to be addressed in the Directory Topology?
The book presents five key issues to be addressed in the Directory Topology. These are resilience, service availability, and performance (includes time response), balance between inquiries and updates, and replication strategy.
Examples of improving resilience involves the duplication of the directory using mirroring techniques to keep systems updated and running. This enables continuity of a key component of the architecture (i.e. AD) in the case one server goes down. The book recommends geographically separated directories and triple-resilient systems for international organizations for service availability. Slave servers stored locally with copies of the directory can increase response time and performance.
What mechanisms within the Physical Layer are where we can implement control points so as to enforce security related time-constraints and sequence constraints?
There are three main mechanisms within the physical layer to enforce security related time and sequence constraints. The first being date and time fields embedded in renewable data structures (e.g. certificates). A signed digital certificate cannot be used past its expiration date once the expiration date is passed.
Second, data and time fields in configuration files that tell you when a control event needs to be executed, with a regular lookup function to compare the current date and time with the event threshold (e.g. antivirus updates set to update daily). Third, is automated timers that are set running at the opening of a period that has a maximum lifetime. Examples include user session lifetime in an application or inactivity timeouts.
Visualizing the Component Layer
In the component layer, special attention is placed on the communication standards used to achieve consistency and inter-interoperability between security architecture components. These standards may be required by the business from major international, national, or industry sector standard-setting bodies. Second, the positioning of protocols within the hierarchy protocol stack. See below for hierarchy:
Additionally in component layer, the most commonly used security products and tools are reviewed for their functions in the business. See top of this page for "Component View" document matching security products to business needs.
A Review of Some Component Layer Protocols:
FTP, FTPS, SFTP
FTP, “file transfer protocol”, is described in RFC 959:
1) to promote sharing of files (computer programs and/or data),
2) to encourage indirect or implicit (via programs) use of remote computers,
3) to shield a user from variations in file storage systems among hosts, and
4) to transfer data reliably and efficiently. FTP, though usable directly by a user at a terminal, is designed mainly for use by programs.
(Postel & Reynolds, 1985)
-Faster file transfer rate than HTTP or email
-Allows the transfer of multiple files, and to multiple directories at one time.
-Ability to resume a file transfer
-Ability to schedule transfer
-Encryption (possible in FTP) is not inherently offered or enforced by all providers (Horan, 2016)
-Not inherently compliant with industry regulations (Horan, 2016)
-Vulnerable to many types of attacks (brute force password attack, packet capture, spoof attack, port stealing)
FTPS, also known as “FTP secure”, “FTP-SSL”, “S-FTP”, is an extension of FTP that uses TLS and SSL cryptographic protocols. Much like HTTPS, FTPS servers must provide a public key certificate. These certificates can be requested and created using tools such as OpenSSL (don’t use!). The certificate provides assurance against a man-in-the-middle attack. If the certificate is not signed by a trusted CA (a self-signed certificate), the FTPS client may generate a warning stating that the certificate is not valid. The client can choose to accept the certificate or reject the connection (FTPS, n.d.).
FTPS is described in RFC 4217:
The security extensions to FTP in [RFC-2228] offer a comprehensive set of commands and responses that can be used to add authentication, integrity, and confidentiality to the FTP protocol. The TLS protocol is a popular (due to its wholesale adoption in the HTTP environment) mechanism for generally securing a socket connection.
-Widely known and used
-Communication can be read and understood by the user
-Provides for server to server file transfer
-Good authentication mechanism in SSL/TLS and x.509 certificates
-SSL/TLS built into many internet communication frameworks
(Secure Black Box, n.d.)
-FTP Servers using OpenSSL framework is vulnerable to heartbleed (Lampe, 2014)
-Does not have uniform directory listing format
-Requires secondary DATA channel, which makes it hard to use behind firewalls
-Does not define a standard for file name character sets
-Not all FTP servers support SSL/TLS
-No standard way to get and change file and directory attributes
(Secure Black Box, n.d.)
SFTP, known as “SSH File Transfer Protocol” or “FTP over SSH”. As FTP’s main purpose is to transfer data at a high rate, the goal of SFTP is to transfer data through secure access to the file system on an FTP server. SFTP runs on top of the Secure Shell protocol and defaults to port 22 for data exchanges (ready to be configured to run on another port to mitigate attacks) (Horan, 2017).
This protocol provides secure file transfer (and more generally file system access). It is designed so that it could be used to implement a secure remote file system service as well as a secure file transfer service.
This protocol assumes that it runs over a secure channel, such as a channel in [RFC4251], that the server has already authenticated the client, and that the identity of the client user is available to the protocol.
When used with the SSH2 Protocol suite, this protocol is intended to be used as a subsystem as described in [RFC4254] in the section "Starting a Shell or a Command". The subsystem name used with this protocol is "sftp".
(Galbraith, J. & Saarenmaa, J., 2006)
RFC 4251 describes three major components of SSH:
The Transport Layer Protocol [SSH-TRANS] provides server authentication, confidentiality, and integrity. It may optionally also provide compression. The transport layer will typically be run over a TCP/IP connection, but might also be used on top of any other reliable data stream.
The User Authentication Protocol [SSH-USERAUTH] authenticates the client-side user to the server. It runs over the transport layer protocol.
The Connection Protocol [SSH-CONNECT] multiplexes the encrypted tunnel into several logical channels. It runs over the user authentication protocol.
(Ylonen & Lonvick, 2006)
-Good standards background which strictly defines most aspects of operations
-Has only one connection (no need for data connection required in FTPS). Strict firewall policies can render SFTP as an easier protocol to use
-The connection is always secured
-Directory listing is uniform and machine readable
-The protocol includes more functions: permissions, attribute manipulation, and file locking
(Secure Black Box, n.d.).
-Communication is binary and can’t be logged for human reading
-SSH keys are harder to manage and validate without an SSH Key management solution:
a) no way to know who has access
b) no tools to remove unauthorized keys
c) no methods to restrict access to private keys
d) no visibility into user activity during SSH sessions
e) Manual setup and maintenance (Cyber Ark, n.d.)
-Standards are define as optional or recommended which provides compatibility issues
-No server-to-server copy and recursive directory removal operations
-No built-in SSH/SFTP support in VCL and .NET frameworks
(Secure Black Box, n.d.)
Implementation: Selecting FTP, SFTP, or FTPS
If the business operates in an industry that handles sensitive information (e.g. ePHI, bank accounts), the clear choice would be to go with encrypted protocols. The selection of SFTP or FTPS depends on the goals and requirements of the organization. Most of these requirements are defined by the servers that the FTP service will be connected to. In general, SFTP is technologically superior to FTPS and is not subject to the Heartbleed vulnerability (or similar vulnerabilities that may emerge). FTPS is used if a server will be accessed from personal devices or operating systems that have FTP but don’t support SFTP clients. SFTP appears to be more popular as Linux and UNIX servers use this service by default (Secure Black Box, n.d.). Setting up FTPS may require the additional configuration of a supported FTP server.
Another key difference includes the business strategic approach involving PKI: FTPS uses x5.09 certificates while SFTP uses SSH keys. With the placement of x.509 certificates, provides for administrative issue considerations (time & cost) and possibly the implementations of x.509 tools. This contrasts SFTP may rely on multifactor authentication and management tools for SSH public keys (FTPS, n.d.)
Example of FTP Exfiltration:
One of Yahoo’s hacker Alexsey Belan, used the file transfer protocol (FTP) to download the Yahoo database, containing usernames, phone numbers, security questions and answers, password recovery emails, and a cryptographic value unique to each Yahoo account (United States of America, 2017).
Cyber Ark. (n.d.). SSH Key Security and Management. Cyberark.com. Retrieved from https://www.cyberark.com/solutions/by-project/ssh-key-security-management/
Ford-Hutchinson, P. (2005, October). Securing FTP with TLS. IETF. RFC 2228. Retrieved from https://tools.ietf.org/html/rfc2228
FTPS. (n.d.). In Wikipedia. Retrieved November 30, 2017 from https://en.wikipedia.org/wiki/FTPS
Galbraith, J., Saarenmaa, J. (2006, July 10). SSH File Transfer Protocol. IETF. Internet-Draft. Retrieved from https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13
Horan, M. (2016, March 1). Key Advantages and Disadvantages of FTP [Web log post]. Retrieved from https://blog.ftptoday.com/key-advantages-and-disadvantages-of-ftp
Horan, M. (2017, June 22). Which File Sharing Solution is Best: FTP or SFTP? [Web log post]. Retrieved from https://blog.ftptoday.com/which-file-sharing-solution-is-best-ftp-or-sftp
Khandelwal, S. (2013, December 10). Security Risks of FTP and Benefits of Managed File Transfer. Retrieved from https://thehackernews.com/2013/12/security-risks-of-ftp-and-benefits-of.html
Lampe, J. (2014, April 10). Managed File Transfer and Heartbleed (Also FTP Servers). Retrieved from http://www.filetransferconsulting.com/managed-file-transfer-heartbleed-ftp-server/
Postel, J., Reynolds, J. (1985, October). File Transfer Protocol. IETF. RFC 959. Retrieved from https://www.ietf.org/rfc/rfc959.txt
Secure Black Box. (n.d.). FTPS (FTP over SSL) vs. SFTP (SSH File Transfer Protocol): What to Choose. SecureBlackBox.com. Retrieved November 30, 2017 from http://www.secureblackbox.com/kb/articles/FTPS-vs-SFTP.rst?page=all
SSH File Transfer Protocol. (n.d.). In Wikipedia. Retrieved November 30, 2017 from https://en.wikipedia.org/wiki/SSH_File_Transfer_Protocol
United States of America v. Dmitry Dokuchaev, Igor Sushchin, Alexsey Belan, Karim Baratov. CR17.103. (2017). Retrieved from
Ylonen, T., Lonvick, C., Ed. (2006, January). The Secure Shell (SSH) Protocol Architecture. IETF. RFC 4251. Retrieved from https://tools.ietf.org/html/rfc4251