GDPR Architects Executive Summary Architects Plans Testing

Intelligent Data access Object for Security
To make the size of our presentation manageable, we are presenting facts based on our research and knowledge. Our attempt here is to present a brief and factual presentation of real world case. Our Architect is a Quick Fix.

Use Case:
              Electronically Hacking, Robbing, Damaging Data of a Financial Institution

Let assume the worst case scenario, where both internal (employees) and external hackers are working together as a team to electronically robe a financial institution.

Briefly Describe This Use Case
Security breaches and what hackers can do check List:

       1. Have all the access login names and passwords
       2. Use a client computer or mobile
       3. Virus which uses the client computer
       4. Interrupting the system
       5. Damage the system data
       6. Stealing Data
       7. Hacking by compressing and/or encrypt system data
       8. SQL Injection
       9. Software bombs
       10. Have all the Authentication and Authorization keys
       11. Continuously test endless combinations of concealed attacks

Primary Actor:
A team of internal (employees) and external hackers.

Prevent any unauthorized access to any account within the financial institution.

Our analysis is done by analyzing the entire system which includes humans (users and IT system developers-hackers), software, hardware, internet, and weak points in the financial software system and operation system. Each could be the weak link for hackers and unauthorized access to breach the system.

How can we prevent any link from being the gate to the system access?
We have to break the norm in the communication between these links since hackers use the norm to gain access.
Our Quick Fix would be running in parallel with the running financial applications.

Our architect would be integrated and running in parallel with all financial applications.
From a 2,000 foot view, our architect has the following functionalities:

       Allows or denies access
       Update the access variables to database.
       Transaction Flag Component as a checkpoint for any possible breach
       Dynamic Business Rules
       Audit trail and tracking of every possible access attempt

Architect Components:

       1. Visiting IDAO
       2. Database Adapter
       3. Transaction Flag Component
       4. Dynamic Business Rules
       5. Proxy Servlet
       6. Implementation of ID and Key_Value security process
       7. Tracking and logging

Cookies Architect
Intelligent Data Access Object for Security Architect Diagram

Intelligent Data Access Object for Security Architect Diagram shows the flow from the outside user to the database access.

Proxy Servlets
The Proxy Servlets would be our first security check point. They are running on the proxy server tier. They will have access to our services and be able to instantiate locally within their methods a security IDAO. They must have an ID and Key_Value and pass them as parameters to instantiate a security IDAO instant. Calling IDAO may have an optional parameter passed to IDAO to save its data, persist in memory or terminate on exist. They would pass a constant such as SAVE_DATA, TERMINATE, KEEP_IN_MEMORY. IDAO would receive both HttpServletRequest and HttpServletResponse and start executing its security methods or processes.

Visiting IDAO
The Visiting IDAO is a Java object which would perform the following:

       Parses or ask questions - checks the HttpServletRequest parameters
       Checks these parameters against the Dynamic Business Rules
       Gives each question or each parse a score
       Adds all the score into a total score
       Checks the total score with Dynamic Business rules to makes a decision
       Gives option to the proxy servlet and the client based on the score
       The options can be:
              Allows access
              Denies access
              Asks the user more questions
              Sends the user a mobile test with ID
              Other option based on the type of business, user, server location, etc.

We just illustrated how IDAO is an intelligent data object. IT parses-asks question, makes, thinks in abstract and gives options.

The following is a code segment

       for(int loop = 0; loop < businessRulesIndexArray.length; loop++) {
                     case IDAO_Constants.CERTIFICATE_INDEX:
                     case IDAO_Constants.COOKIES_INDEX:
                            Cookie [] localCookies = request.getCookies();
                     case IDAO_Constants.LOCALES_INDEX:
                     case IDAO_Constants.LOCALE_INDEX:
                     case IDAO_Constants.LOCAL_ADDRESS_INDEX:
                     case IDAO_Constants.LOCAL_PORT_INDEX:
                     case IDAO_Constants.REMOTE_ADDRESS_INDEX:
                     case IDAO_Constants.REMOTE_HOST_INDEX:
                     case IDAO_Constants.REMOTE_PORT_INDEX:
                     case IDAO_Constants.REMOTE_USER_INDEX:
                     case IDAO_Constants.REQUEST_URL_INDEX:
                     case IDAO_Constants.SERVER_PORT_INDEX:
                     // default check;
              public int getSecurityTotalScore(){

The code segment is an illustration of how to use business rules and "HttpServletRequest request" and "HttpServletResponse respond" to parse the proxy request for security access. IDAO would also parse Cookies. Based on the security score calculated by IDAO, this would give proxy servlets the ability to make security decisions. The following code segment presents a roof draft of decision making code based and the business rules.

       int localSecurityScore = localSecurityIDAO.getSecurityScore();

       which(localSecurityScore) {
              case XX_123: do_xyz();
              case XX_DENY_SERVICE: denyService();

IDAO gives the Proxy servlets the ability to deny service, ask more security questions, send a text message with a code to client client's mobile or perform other security processes. Security Dynamic Business Rules would add flexibility to the proxy servlets handling security. Such rules can be edit and changes by system admin based the running business requirements.

Transaction Flag Component:
The main object in integrating our software components is not to interrupt the running applications nor require any additional code or testing. We would create an alias to database servers and redirect all SQL calls to our Transaction Flag Component. Our Transaction Flag Component is designed to:

       Receive any running application SQL calls to a target database
       Parse the calls looking of issues (SQL Injection, any misuse, .. etc) and flag them to security handlers
       If there is no issues or alarms, redirect the calls to the traget database
       Performs audit trial and tracking

Creating Server Alias:
An alias is an alternate name that can be used to make a new connection. The alias encapsulates the required elements of a connection string, and exposes them with a name chosen by the user. Aliases can be used with any running application. By creating server aliases, any application can connect to multiple servers using different network protocols, without having to specify the protocol and connection details for each one.

Code refactoring is the process of changing a computer program's internal structure without modifying its external functional behavior or existing functionality.

All the refactoring that would be done on the IDAO, business rules and or proxy servlets local methods to handle new security changes, would not have any impact or side effects on the running system. Security Business Rules files would give the system admin the ability to dynamically change rules on the run.

Database Adapter:
Our architect will integrate into any environment and any database. There is no environment requirement since our architect is integrated into any system without interruption. As for security, our ID and Key Values checks would prevent any security access issues. Java code for logging would require minor changes and testing. These minor changes can be implemented with automated addition of few text lines of Java code as a logging revision.

ID and Key Value Integration:
Creating ID and Key Values as tracking and security measures is very simple and can be automated. Their functionalities are as follows:

Any Java function must have an ID with function name, java class-object, package, etc. It is converted into a long integer which can be parsed and evaluated. We do recommend these values should not be changed but only on the needed basis.

Key Value
The same concept as ID but it has a time stamp integrated into the long integer. The value of the Key must be periodically changed and updated.

Adding ID and Key Value to any method would be done as one two lines of text to the code:

       public void anyMethodBySam {
              // added ID and Key Value at the start of the method with variable the same names used in every methods.
              long localID = 1234665556789; long localKeyValue = 9876123454345;
              IDAO_Security localIDAO_Security = new IDAO_Security(...,localID, localKeyValue );

Logging Integration:
Logging code and calls must be revised to add to traps and tracking of unauthorized code calls and access. The same ID and Key Value principles can be used.

Only Our Code Would Be Running and not a Copy or a Clone:
All the methods in our architect components must have an ID and Kay_Value numbers which would be loaded dynamically with the call to this method. In short every method must call for the ID and Kay_Value numbers method and gets such number to pass it to the next callers and the Log-Tracking. The dynamic business Rules will provide such ID and Kay_Value. Every method must check the ID and Kay_Value numbers for authentication by calling the authentication method and get its approval. This would prevent any code copying and running by some components which is not our code.

Intelligent Data Access Object (IDAO):
We need to ask these questions:
How to make data intelligent?
What are the cost and time required to make data intelligent?
Can we automate adding intelligence to data?
Intelligence and learning must be ongoing processes, how do we achieve them efficiency and economically?
How do we perform the data conversion without any system interruptions?
What type of tools do we need to create which help with data intelligence conversion?

Intelligence is the ability to make decision and learn as you go. Therefore, we need to combine data and decision-making in one object which we call Intelligent Data Access Object (IDAO). Plus we need to insure that we are doing the right processes in making IDAO. Therefore IDAO must be tested and pass the tests.

We need to create Business Rules and Decision-making code to add intelligence to our IDAO.

Adding Intelligence:
Adding intelligence to Data Access Object (DAO) is combination of pure data (DAO with set() and get() methods) plus Intelligence Building.

What is Intelligence Building?
Intelligence Building is simply the following steps:

Adding steps-code-methods which collect the needed data for processing
Collecting the actual values to be stored in IDAO
Each method checks incoming data with existing data for accuracy and relationships and returns a score based on the dynamic business rules.
Decision-making based on dynamic business rules
The decision-making method will add all the scores and decides on the course of actions.
Statistic Pool
Tracking the success-failure of each method and each data for future IDAO enhancement (learn as you go).

Conceptually, we are turning decision-making into mathematical formulas that use business rules values to choose a course of actions.

       Facebook Facebook Facebook Facebook Facebook
About us Contact Site Map Support Privacy Terms All rights reserved