SecureWithin™ addresses two main IT objectives:
SecureWithin™ logs, notifies and manages important aspects of web services, web applications and other types of computing endpoints offering the strongest feature set, ease of use, scalability, performance and security on the market but unlike any other product it does NOT require network or firewall re-configuration or client-side software.
The core software is comprised of two collaborating gateways – internal (on the LAN) and external (on the Internet). Before collaborating with the external gateway for the first time and periodically on a configurable time interval, the internal gateway communicates with the Bitkoo metadata service to retrieve data that contains, among other things: information about internal endpoints/services to expose, security requirements, optional data transformation and on which external gateways to make the services available. The metadata is defined by customers on Bitkoo’s secure website.
Any metadata changes made by customers are logged in a detailed audit trail. Customers must authenticate using a user Id assigned by Bitkoo and a strong password chosen by the customer. In addition, when calls are made to the Bitkoo metadata service by gateway devices, the calls are authenticated using an X.509 certificate residing on the calling device.
Once the internal gateway receives its applicable metadata, it is aware of which internal endpoints to make available to outside clients and what security rules apply to the endpoints. It also knows on which external gateways to expose the endpoints to Internet clients. It calls the external gateway(s) using HTTPS (SSL) over port 443. The usage of this protocol and port is typically allowed by most organizations and firewall configurations permit the traffic to flow freely. If an organization does not allow SSL traffic for some reason, SecureWithin™ can handle communications to the metadata service and the external gateway over port 80 with the HTTP payload encrypted.
A set of persistent connections is established between the internal gateway and the external gateway. The external gateway exposes TCP/IP ports as defined by the customer. When defining how endpoints will look to external clients, the customer may indicate the exact port number, service name and host name. To Internet clients, the newly exposed external gateway looks exactly like the internal endpoint which it expose or alternatively, if a transformation was specified – looks completely differently.
The external gateway receives its configuration data by contacting (on a configurable periodic basis) the Bitkoo metadata service. It too authenticates itself to the metadata service using X.509 certificates.
Internally, as calls are made from Internet clients to the external gateway, they are queued in memory and pulled by the internal gateway that already established a persistent connection earlier over SSL. The internal gateway evaluates the request against a set of security rules to ensure that the request is valid, non-malicious and legit. If it passes the security validation step, it is optionally logged. The logging can be configured to record the entire request/response, just the request or the response, key elements about of request, just the origin and timestamp, etc.
Invalid requests are logged as well, with identical requests being logged intelligently as to avoid exhaustion of the storage device. Algorithms are in place to defend against denial of service attacks or intrusion attempts. The software actively protects against such attacks by blocking subsequent requests from suspect clients. In addition, the software alerts Bitkoo personnel and designated customer personnel of attacks in real time via multiple configurable channels (Email, Web Services or SMS messages). When a request is determined to be valid, the internal gateway calls the LAN-based endpoint using the appropriate credentials. The original request is optionally transformed. The optional transformation is defined as part of the customer-defined metadata.
Upon a response from the endpoint, depending on the type of endpoint and how the metadata was defined, the request is sent back to the external gateway over the already established communications channel and the external gateway correlates the response to the correct caller and sends the response to the client. A transformation step can optionally occur at this stage as well and as described before the transformation is an aspect defined in the customer definable metadata.
From all described thus far, the SecureWithin™ architecture extends the internal network to the external Internet (or other networks) by marshalling all requests/responses via an existing firewall using well known and allowed ports, without having to re-configure or poke holes in the firewall. Sophisticated algorithms are used to guarantee security and high throughput.
To read more about the business drivers for a solution like SecureWithin™ , download SecureWithin™ - Complete Endpoint Security.