Enterprise Security Architecture System Proposal ...



Enterprise Security Architecture System Proposal: Intergalactic Banking and Financial Services, Inc FY 2017“If you spend more on coffee than on IT security, you will be hacked. What's more, you deserve to be hacked” ― Richard ClarkeContents TOC \o "1-1" \h \z \u Overview PAGEREF _Toc500751514 \h 1 HYPERLINK \l "_Toc500751515" Detailed Data Structure Specifications PAGEREF _Toc500751515 \h 2 HYPERLINK \l "_Toc500751516" Security Standards PAGEREF _Toc500751516 \h 6Implementation: PAGEREF _Toc500751517 \h 8Conclusion PAGEREF _Toc500751518 \h 12References PAGEREF _Toc500751519 \h 13OverviewHighlightsIntergalactic Banking and Financial Services, Inc (IBFS) is a collection of companies that operate in the global market of banking and finance products/services. They have a large, multi-pronged list of products and services that they offer to their business customers. IBFS is currently in the process of further developing their web and email services to facilitate growth. To date, their approach to the afore mentioned effort was to procure and integrate ad-hoc systems and incorporate them into the enterprise architecture. “Now IBFS needs to take a much more strategic approach by developing infrastructure (both technology and process) that will enable a wide range of new business applications” CITATION Joh05 \l 1033 (John Sherwood, 2005). This assessment will address IBFS’s desire to develop an enterprise security architecture utilizing the Component Layer of the SABSA Model as the framework. The Component Layer of the SABSA Model is also considered the Tradesman’s View. Construction projects call upon the expertise of a collection of tradesmen to bring the project to life. For an enterprise security architecture to function properly, its components must be integrated to work together. The component security architecture is concerned with:Data field specifications, address specifications and other detailed data structure specificationsSecurity standardsProducts and tools (both hardware and software)User identities, privileges, functions, actions and access control lists (ACLs)Computer processes, node addresses, and inter-process protocolsSecurity step timings and sequencingMany businesses have interactive, business critical applications that must account for the ability to be enhanced or upgraded. “Typical changes are migration to client/server, accessibility via Intranet/Internet, changed business needs, improving maintainability, to mention a few. In order to give an idea of the significance of this area: the majority of the code maintained in the world is a part of a transaction system and this trend will continue” CITATION Ale02 \l 1033 (Alex Sellink, 2002). The following sections will address each of these concerns, specific to IBFS, based on the expressed interests of key leadership within IBFS.Detailed Data Structure Specifications“At the Component Layer of any architecture it is essential that the various components selected from different vendors should be capable of being plugged together to build integrated structures” CITATION Joh05 \l 1033 (John Sherwood, 2005). IBFS envisions a single central data repository for customer data. Currently, their information system applications architecture is a collection of legacy applications with a stovepipe architecture. Ranjit Patel of IBFS expressed specifically that their legacy applications must integrate into the new architecture. They can’t simply remove the legacy applications for multiple reasons:Major global and Fortune 100 clients who transfer large sums of money on a given transaction utilize a network of legacy systems making it unacceptable to simply get rid of the legacy systemsCost of reengineering the systems is prohibitiveGiven this list of constraints affecting the possible technological solutions available to IBFS, the security architect is only left with the option to develop a solution that incorporates the legacy systems. Therefore, the Detailed Data Structure Specifications must define the syntax and taxonomy of the information being transferred between new and legacy systems. This process involves updating the IBFS Data Dictionary that was developed in a previous layer of the SABSA Model. To update the current Data Dictionary, I assessed the current data transaction systems against possible solutions that could be implemented based on the list of IBFS technologies. Below is a snapshot of the proposed transaction types performed to be implemented within the updated Security Architecture:Variable Name/ LabelData TypeSizeDescription/ PurposeStage TransactionGenerate a unique key (TransportKey) using createTransaction web service method to stage the transaction parametersInitiate TransactionSend the TransportKey to the Customer Engagement Device using the GET method and allow customer time to complete the transactionAfter the transaction is completed, the device sends response back in XML, JSON or JSONP formatRetrieve DetailsUse the DetailsByTransportKey web service method to retrieve additional payment infostockNameString1-160Name of the business/ org owning the Stock accountstockSiteIDString8-160Stock identifier owned by the companystockKeyString1-160Software key or password for the entity accessing the Stock accountRequestTransportRequestTransportRequest object containing the transaction dataTransactionTypeString4-14SALEPREAUTH - preauthorizes card onlyPOSTAUTH - captures transactionCANCELAmountDecimal0-99,999Desired amount for transactionOrderNumberString1-8The order or invoice number associated with the transactionSoftwareNameString1-50The name of the software application sending the requestSoftwareVersionString1-25The version number of the software application sending the requestTransactionIdString1-100The Stock-owner defined identifier for the transactionForceDuplicateBooleanOverride duplicate protection and allow the transaction to process normallyTRUEFALSECustomerCodeString1-50Rquired for higher level transactions requiring raised authorization privilegesStatusStringThe status of the transactionAPPROVEDDECLINEDUSERCANCELLEDPOSCANCELLEDAmountApprovedDecimalAmount transaction was approved forAuthorizationCodeStringAuthorization Code issued by the processor upon receipt of a transactionAccountholderStringName associated with the accountAccountNumberStringString representing the account number of the account holderErrorMessageStringMessage representing why the transaction could not be processedTransactionDatedateTimeDate and time of the transaction in UTC timeTransactionTypeenumThe type of transaction and the value matches up with the TransactionType enumerationSALEAUTHORIZATION ValidationKeyStringThis ValidationKey should be used to match up with the ValidationKey received during the initiation of the transaction call to validate the transaction process Table 1: Updated Data Dictionary reflecting financial transaction stringsSecurity StandardsIncorporating Security Standards to answer the “why” certain security tools, processes, and procedures are implemented is a necessary part of any enterprise security architecture. Standards enable cohesion and interoperability within the entirety of the architecture to create seamless flow in operations. “If every component were built to a unique interface specification, nothing would ever work together” CITATION Joh05 \l 1033 (John Sherwood, 2005). IBFS is a global organization and must also incorporate standards that consider the 30+ countries where its satellite offices reside. Below is a list of standards considered for implementing information security solutions within the IBFS Enterprise Security Architecture:StandardDescriptionInternational Organization for Standards (ISO)Worldwide federation of national standards bodies from more than 140 countries. The organization, itself, promotes the development of standardization and related activities in the world with a view to facilitating the international exchange of goods and services, and to developing cooperation in the spheres of intellectual, scientific, technological and economic activity.ISO21188:2006Public key infrastructure for financial servicesISO 8583An international standard for?Financial transaction card originated?interchange messaging. It is the?International Organization for Standardization?standard for systems that exchange electronic transactions initiated by cardholders using?payment cards.PCI DSSThe Payment Card Industry Data Security Standard (PCI DSS) is a set of security standards designed to ensure that ALL companies that accept, process, store or transmit credit card information maintain a secure environment.NIST 800-63Provide technical guidelines to agencies for the implementation of digital authentication.Patch Management StandardInternally developed standard that outlines requirements that addresses the interval at which systems are to be patched and updated as well as delegating roles and responsibilities to those performing the maintenance. Example: Vulnerability scans shall be used to determine and report the state of systems or applications with regard to flaw remediation.610047371026670"PKI by itself does not provide security unless it is used in conjunction with other solutions (and) communication platforms like email (or) mobile device management (MDM)" (Lawton, 2015).020000"PKI by itself does not provide security unless it is used in conjunction with other solutions (and) communication platforms like email (or) mobile device management (MDM)" (Lawton, 2015).Implementation:95250945515Stock Companies00Stock Companies3434715774065User and Stock Company Data00User and Stock Company DataImplementation summarizes the products and tools, user identities, privileges, functions, actions and access control lists (ACLs), computer processes, node addresses, and inter-process protocols, and security step timings and sequencing.The image above represents the architecture for IBFS. Each component and interface is labeled with a corresponding number. Below, outlines each of the components and implementations for the security architecture. This is only a snapshot of the US based site. Components#1 Customers: Establish a TLS 2.0 connection to the Web server using Curve25519. Curve25519 is an elliptic curve Diffie-Hellman (ECDH) key exchange protocol that has gained popularity because it is efficient, secure, and easy to implement. It was adopted by the Internet Engineering Task Force (IETF) as an approved method of implementing cryptographic keys. “The implementation requires only 3 589 850 cycles, which is a factor of 3 faster than the scalar multiplication on the NIST P-256 curve” (Düll, 2015).“It is based on arithmetic on the Montgomery curve Curve25519 with equationE : y2 = x3 + 486662x2 + xdefined over the field F2^255-19” (Düll, 2015). In an article presented by MDPI, several tests were conducted to compare several public-key algorithms (RSA, Diffie-Hellman, NIST P-256, Curve25519, and FourQ), Curve25519 beat RSA, Diffie-Hellman, and NIST P-256.The PKI Intermediate CA server will authenticate customers to the web server.#2 Stock Companies: Establish a TLS 2.0 connection to the Web server using Curve25519. The PKI Intermediate CA server will authenticate providers to the web server.#3 Remote Workers: Require remote workers to utilize the same digital certificates employed within the corporate LAN managed by the PKI Intermediate CA server. Establish symmetric cryptographic connections using OpenIKED for IPSec VPN connections. Design OpenIKED for AES-GCM 256 because it provides both confidentiality and authentication. Employees can be issued company owned devices that are imaged with VPN software like Cisco AnyConnect. A connection to the organization’s internal network can be established by starting the application and using the employee’s pin number. #4 Off-Site Backup: Employ AES-GCM 256 to ensure that as information is backed up it is done using a secure connection. Utilize Curve25519 for connections to the offsite backup server.#5 Outer Firewall: Disallow ports for Telnet (23), FTP (20,21), etc. to prevent confidential information from being transmitted in clear text.#6 Web Servers: Configure customer facing webserver for TLS 2.0 and ensure the server has vetted certificates from the CA. Use TLS 2.0 protocol SHA-512 hashing. Utilize Curve25519 as the symmetric algorithm for establishing the connection. The web server will also utilize the capabilities of the Intermediate CA server to authenticate clients (customers and providers).#7 VPN: Configure the VPN for IKEv2 for OpenIKED. Remote workers will authenticate to the corporate LAN using the Intermediate CA server. As NIST puts it, “the use of encrypted VPNs does not make the access non-remote; however, the use of VPNs, when adequately provisioned with appropriate security controls (e.g., employing appropriate encryption techniques for confidentiality and integrity protection) may provide sufficient assurance to the organization that it can effectively treat such connections as internal networks” CITATION Nat13 \l 1033 (Technology, 2013). Incorporating an automated monitoring capability can help detect attacks during a remote session. Cisco AnyConnect includes a VPN monitoring capability.#8 Inner Firewall: Disallow ports for Telnet (23), FTP (20,21), etc. to prevent confidential information from being transmitted in clear text.#9 User and Stock Company Data: Configure servers to employ HMAC-256. Configure servers for Curve25519 connections. Employees can establish connections to the User and Provider Data server using Kerberos GSS-API to establish a connection to the server.#10 Corporate LAN: Employ the use of digital signatures for non-repudiation within the organization’s infrastructure for passing email traffic and signing electronic documents. Implement PKI using RSA algorithm. Employ a Kerberos server using the Kerberos GSS-API mechanism for Windows environments. Be sure not to allow applications like Telnet and FTP. The LAN will also have an Intermediate CA server to manage certificates, for sending emails, signing electronic docs, authenticating to servers (web server access for clients and remote workers using VPN), and managing access control within the LAN. The network will also be equipped with a separate Root CA that will host the keys and remain offline until the issuance of new keys is necessary. Keys will set expire annually. #11 Wireless Access Point: WPA 2 AES encryption#12 Corporate Data: Employ a Kerberos server using the Kerberos GSS-API mechanism for Windows environments.Interfaces#13 Customers to Outer Firewall: Use the TLS 2.0 protocol with SHA-512 hashing. The security team can then truncate 256 bits of output and provide the organization 128 bits of security. Establish the TLS connection using Curve25519. TLS connections can be used in conjunction with SASL for added security, but is not necessary. Customers will authenticate to the web server using PKI.#14 Stock Companies to Outer Firewall: Use in the TLS 2.0 protocol SHA-512 hashing. The security team can then truncate 256 bits of output and provide the organization 128 bits of security. Establish the TLS connection using Curve25519. Establish the TLS connection using Curve25519. TLS connections can be used in conjunction with SASL for added security, but is not necessary. Providers will authenticate to the web server using the capabilities PKI.#15 Remote Workers to VPN: Configure the VPN for IKEv2 for OpenIKED. Remote workers will authenticate to the corporate LAN using the Intermediate CA server.#16 Outer Firewall to Web Servers: Use the TLS 2.0 protocol with SHA-512 hashing with Curve25519. Establish the TLS connection using Curve25519. TLS connections can be used in conjunction with SASL for added security, but is not necessary.#17 Web Servers to Inner Firewall: HMAC-SHA-256 through to connections to servers within the corporate LAN and truncate. #18 VPN to Inner Firewall: Curve25519 provides enough security for remote clients and does not need Kerberos security for these connections.#19 Inner Firewall to Corporate LAN: Curve25519#20 Inner Firewall to User and Provider Data: HMAC-SHA-256 be sure to truncate for 128 bits of security. Establish Curve25519 connections#21 Corporate LAN to User and Provider Data: HMAC-SHA-256 be sure to truncate for 128 bits of security. Establish Curve25519 connection. PKI used to manage access to data through an assigned set of roles and groups assignments. Since this is a Windows based network, IBFS will utilize the GSS-API implementation throughout the network. Connections to the critical servers made within the confines of the organization’s LAN would utilize GSS-API Kerberos implementation. “Active Directory uses a field in the Kerberos ticket called “authorization data” to store the Microsoft PAC (Privilege Attribute Certificate). Among other things, the PAC includes a set of Security Identifiers (SIDs) for the client” CITATION MIT08 \l 1033 (MIT, 2008). I would implement a primary and secondary KDC (to serve as a slave to the primary KDC) to protect against critical failures.#22 Wireless Access Point to Corporate LAN: Establish Curve25519 connection.#23 Corporate LAN to Corporate Data: For connections behind the webserver, including remote employees using a VPN tunnel, connections use HMAC-SHA-256 (this implementation can also be truncated to provide 128 bits of security). Establish Curve25519 connection. PKI used to manage access to data through an assigned set of roles and groups assignments.ConclusionIBFS is at a stage in its existence where it must meet the demands of the current market by growing into this new and emergent environment. It can only do so, and be successful, by developing an enterprise security architecture that is caters to the specific needs of IBFS. The future is here. IBFS must keep pace with the pace at which society embraces technology and incorporates it into their daily lives. Each new gadget, tool, system introduced into the IBFS environment poses a threat to the confidentiality, integrity, and availability of our data. Which means that an attack on our network can bring about insurmountable losses, especially if IBFS is found to be non-compliant to regulatory standards. IBFS must respond to this threat environment with a comprehensive cybersecurity plan that is robust, simple, and meets regulatory standards. This proposal suggests just such a solution.References BIBLIOGRAPHY Alex Sellink, H. S. (2002). Restructuring of COBOL/CICS legacy systems. Science of Computer Programming, 193-243.John Sherwood, A. C. (2005). Enterprise Security Architecture: A Business-Driven Approach. Boca Raton, FL: Taylor & Francis Group, LLC.MIT. (2008, July 23). Best Practices for Integrating Kerberos into Your Application. Retrieved from Kerberos Consortium: , N. I. (2013, April). NIST 800-53 R4. Gaithersburg, Maryland, US. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download