|
Intelligent Data access Object for Security
Introduction
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
Description:
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.
Goals:
Prevent any unauthorized access to any account within the financial institution.
Analysis
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.
Architect
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
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++) {
...
switch(businessRulesIndex)
{
case IDAO_Constants.CERTIFICATE_INDEX:
...
break;
case IDAO_Constants.COOKIES_INDEX:
Cookie [] localCookies = request.getCookies();
...
break;
case IDAO_Constants.LOCALES_INDEX:
...
break;
case IDAO_Constants.LOCALE_INDEX:
...
break;
case IDAO_Constants.LOCAL_ADDRESS_INDEX:
...
break;
case IDAO_Constants.LOCAL_PORT_INDEX:
...
break;
case IDAO_Constants.REMOTE_ADDRESS_INDEX:
...
break;
case IDAO_Constants.REMOTE_HOST_INDEX:
...
break;
case IDAO_Constants.REMOTE_PORT_INDEX:
...
break;
case IDAO_Constants.REMOTE_USER_INDEX:
...
break;
case IDAO_Constants.REQUEST_URL_INDEX:
...
break;
case IDAO_Constants.SERVER_PORT_INDEX:
...
break;
default:
// 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();
default:
...
}
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.
Refactoring:
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:
ID
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:
•
|
Planning
Adding steps-code-methods which collect the needed data for processing
|
•
|
Collection
Collecting the actual values to be stored in IDAO
|
•
|
Processing
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.
|
|
|