Keeping Clockworks Secure



System Integration Security

  • Data Access: All methods of integration with controllers, devices, and equipment using various data collection protocols are one way read only within the local area network thus preventing any reverse writing capabilities. Data is sent out using common mature secured communication protocols http(s) and traffic ports. All traffic is outgoing, and nothing is actually served.
  • Network: All integration hardware is placed within the existing internal LAN following suit with all existing network and firewall security settings. No need for opening additional ports or altering firewall settings. This may or may not be public facing with or without internet access.
  • Internet Access: With use of dual Ethernet cards it provides us the ability to configure access to the control system on one network or subnet and data delivery on another. With this level of isolation, internet access can be provided to one network and not the other, as well as enabling the ability for separate firewalls and security measures.
  • Traffic Security: No port forwarding to our machine will prevent any entry points or gateways.
  • Remote Desktop Access: Optional
  • Obfuscation: All software integration methods are obfuscated and compiled as executables and then installed.
  • Encryption: Optional data encryption during transfer.
  • Authentication: Cert based authentication.

Microsoft Azure Cloud Security

Naturally the idea of having sensitive business data "floating around out there" makes people nervous. By nature people and especially IT administrators are not at all comfortable with not knowing exactly where their data is physically located, if and how it is encrypted, exactly how much it's intermingled with the data of the cloud vendor's other clients and who has access to it.

Here's some of the many various measures Microsoft has implemented to reassure security:

  • Subscriptions Authentication: Subscription based access with windows live id, one of the longest running Internet authentication services available, and thus provides a rigorously tested gatekeeper for Windows Azure.
  • Access control for Hosted Services and Storage Accounts governed by the subscription.
  • Service Management API (SMAPI) authentication is based on a user-generated public/private key pair and self-signed certificate registered through the Windows Azure Portal. The certificate is then used to authenticate subsequent access to SMAPI. SMAPI queues requests to the Windows Azure Fabric, which then provisions, initializes, and manages the required application.
  • Storage Account Key: Access to Windows Azure storage is governed by a storage account key (SAK) that is associated with each Storage Account. Storage account keys can be reset via the Windows Azure Portal or SMAPI.
  • Confidentiality ensures that a customer’s data is only accessible by authorized entities. Windows Azure provides confidentiality via the following mechanisms:
    • Identity and Access Management - Ensures that only properly authenticated entities are allowed access.
    • Isolation - Minimizes interaction with data by keeping appropriate containers logically or physically separate. Including Isolation of Hypervisor, Root OS, Guest VMs, Fabric Controllers, Packet Filtering, VLAN, and Customer Access.
    • Encryption - Used internally within Windows Azure for protecting control channels and is provided optionally for customers who need rigorous data protection capabilities.
  • Least Privilege Customer Software: Running applications with “least privilege” is widely regarded as an information security best practice. To align with the principle of least privilege, customers are not granted administrative access to their VMs, and customer software in Windows Azure is restricted to running under a low-privilege account by default (in future versions, customers may select different privilege models at their option). This reduces the potential impact and increases the necessary sophistication of any attack, requiring privilege elevation in addition to other exploits. It also protects the customer’s service from attack by its own end users.
  • SSL Mutual Authentication for Internal Control Traffic: All communications between Windows Azure internal components are protected with SSL. In most cases, the SSL certificates are self-signed. Exceptions are for any certificates for connections that could be accessed from outside
  • Certificate and Private Key Management: To lower the risk of exposing certificates and private keys to developers and administrators, they are installed via a separate mechanism than the code that uses them. Certificates and private keys are uploaded via SMAPI or the Windows Azure Portal as PKCS12 (PFX) files protected in transit by SSL. Those PKCS12 files may be password protected, but if so, the password must be included in the same message. SMAPI removes the password protection (if necessary) and encrypts the entire PKCS12 blob using SMAPI’s public key and stores it in a secret store on the FC, along with a short certificate name and the public key as metadata.
    The configuration data associated with any role within the same subscription specifies the certificates that should be made available to the role. When a role is instantiated on a VM, the FC retrieves the appropriate certificate, decrypts the PKCS12 blob, re-encrypts it using the FA’s public transport key, and sends it to the FA on the node. The FA on the node sends it to the GA in the VM that is instantiating the role, and then the GA decrypts it and installs it in the operating system certificate store with a flag indicating that the private key can be used but not exported. After installation, all temporary copies of the certificates and keys
  • Hardware Device Credentials Used by the FC: In addition to application keys, the FC must maintain a set of credentials (keys and/or passwords) used to authenticate itself to various hardware devices under its control. The system used for transporting, persisting, and using these credentials is designed to make it unnecessary for Windows Azure developers, administrators, and backup services/personnel to be exposed to secret information. Encryption based on the FC’s master identity public key is used at FC setup and FC reconfiguration time to transfer the credentials used to access networking hardware devices, remote power switches on the racks that are used to power cycle individual nodes, and other systems. The FC maintains these secrets in its internal replicated data store (still encrypted with its master
  • Deletion of Data: Where appropriate, confidentiality should persist beyond the useful lifecycle of data. Windows Azure's Storage subsystem makes customer data unavailable once delete operations are called. All storage operations including delete are designed to be instantly consistent. Successful execution of a delete operation removes all references to the associated data item and it cannot be accessed via the storage APIs. All copies of the deleted data item are then garbage collected. The physical bits are overwritten when the associated storage block is reused for storing other data, as is typical with standard computer hard drives.
  • Integrity: Customers seeking to outsource their data compute and storage workloads to Windows Azure obviously expect it to be protected from unauthorized changes. Microsoft’s cloud operating system provides this in a number of ways.
  • Availability: One of the main advantages provided by cloud platforms is robust availability based on extensive redundancy achieved with virtualization technology. Windows Azure provides numerous levels of redundancy to provide maximum availability of customers’ data. Data is replicated within Windows Azure.
  • Accountability: Because cloud computing platforms are effectively an outsourced computing environment, they have to be able to demonstrate safe operation to customers and their designated agents on a regular basis. Windows Azure implements multiple levels of monitoring, logging, and reporting to provide this visibility to customers.
  • Network Administration: Windows Azure internal network is isolated by strong filtering of traffic to and from other networks. This provides a “backplane” for internal network traffic that is high-speed and at low risk from malicious activity generally.
  • Physical Security: A system cannot be more secure than the physical platform on which it runs. Windows Azure runs in geographically distributed Microsoft facilities, sharing space and utilities with other Microsoft Online Services.
  • Facilities Access: Microsoft uses industry standard access mechanisms to protect Windows Azure’s physical infrastructure and datacenter facilities. Access is limited to a very small number of operations personnel, who must regularly change their administrative access credentials. Datacenter access, and the authority to approve data center access, is controlled by Microsoft operations personnel in alignment with local data center security practices.
  • Power Redundancy and Failover: Each datacenter facility has a minimum of two sources of electrical power, including a power generation capability for extended off-grid operation. Environmental controls are self-contained and remain operational as long as the facility and contained systems remain online. Physical security controls are designed to “fail closed” during power outages or other environmental incidents. In case of fire or situations that could threaten life safety, the facilities are designed to allow egress without remaining exposed.
  • Media Disposal Upon systems end-of-life, Microsoft operational personnel follow rigorous data handling procedures and hardware disposal processes.


Clockworks Security

  • Sitewide: SSL, HSTS, Session timeouts and expiration. Permanent redirect https.
  • Login: Username and password hash, minimum character length, captcha, failed authentication lockout, and account disabling.
  • Roles: Role based users.
  • Buildings: Building based restricted users.
  • Modules: Module based restricted users.
  • Cookies: No sensitive data is stored using cookies. Http only requiring SSL.
  • Web Services: Username and password hash. Security keys. Certificate based authentication.
  • Incoming Data: Data source verification and security measures.
  • Storage: Using X.509 certs for authentication. Application uses SMAPI to gain access to storage keys. No storage keys stored at rest. All non-relational data stored on the cloud is anonymized.
  • Blob: Serialization and compression.


Additional Microsoft Azure References