Increasing Distributed IT & C Application Security

The development of distributed IT & C applications – DIA is presented alongside their main characteristics and the actors involved in activities through-out their lifecycle are identified in the before-mentioned scope. Aspects pertaining security risks, as well as methods of enhancing security, are detailed by DIA architectural features. The analysis includes risk elements, vulnerabilities, means of enhancing the behavior of the system, as well as a hierarchical feature dependency model based on a qualitative assessment of DIA security features, obtained through an inquiry in the common means of protection used by Romanian professionals, as well as their prioritization in the context of limited resources. A graph-based model of feature interactions is built. The last section deals with the ways of improving risk detection methods, as derived from the answers and features presented.


DIA Development
Today's developed informational society involves the implementing of distributed applications, software characterized by components that are either shared by multiple operatorscommon databases, or part of a larger, enveloping system.Distributed IT Applications -DIAsdefine collections of software modules separated based on function or location and interacting in a structured manner in order to provide an optimized solution to a request.DIAs are characterized by the existence of components with varying degrees of interdependency, differentiated by role, software technology and geographical location, communicating in a synchronous or asynchronous manner in solving a task.One particularity of such systems is the existence of multiple processing nodes.DIA components are characterized by:  diversity , in the sense that module development technologies vary widely; the layered architecture of the systems increases the array of tools for implementing the required components, as database management systems, integrated development environments, logging & system auditing are used together in providing better solutions;  functional orientation, each component having a pre-determined, well defined role in the system; communication, computing the input, auditing, authorization, authentication, encryption, maintenance form the array of tasks that characterize distributed application subassemblies;  technical autonomy, the property of a component to function even if other components it interacts with are not accessible; data access and operation security is increased by the usage of duplicate modules, of independently operating computing units and load balancers that besides splitting the workload act towards redirecting jobs in case an error occurs or a component becomes unavailable;  logical autonomy, derived as a notion from the technical one, but encompassing a module's ability to perform its individual tasks at maximum efficiency and without waiting for an external process-based input; when the latter is required, the interaction occurs asynchronously; parallel processing software, acting in the solving of complex problems requiring large amounts of computing power, solve the issues by separating tasks based on the 1 DOI: 10.12948/issn14531305/17.2.2013.13degree of interdependency in obtaining the results, analogous to an algorithm for solving a system of equations, in which the order of the initial computations is irrelevant as long as they are all applied;  redundancy, the presence of common functions in more than one component, used to improve system-wide performance or as backup in case an incident occurs; the sensitive nature of financial and security systems, as well as public services, leads to architectures using components performing identical tasks and auditing of the same data set information at multiple points in the system.Distributed systems are identified with respect to the manner in which resources are accessed, as parallel or concurrent.An application's components behave in a client or server manner in exchanging information, although the 2 categories are not well delimited.Geographically dispersed users access the application through complex networks in their effort to connect to an often unique pool of resources.Distributed computing allows for creating roles with regard to the interactions between components, as each module interacts with at least one other in requesting input and providing results.Additionally, roles are not required to be mutually exclusive, although they are built with a predefined scope and share resources accordingly.The software application lifecycle starts with the decision of meeting an organization, group or individual's demands through the development of task-specialized tools that improve on productivity by the direct or indirect management of economic, social, educational or cultural interactions over uncertain output generation Actors involved in DIA functional analysis are tasked with the mapping of the desired behavior to documents and analytical tools, as well as with passing the translated information to subsequent parties involved in the design and development of the distributed application.Understanding the roles they play leads to evaluating the impact of their actions in the operability and security of the resulting system, with effects in risk assessment and damage control.In order of the functional to technical orientation that activities they are responsible for show:  users or customers that will operate directly on the application or supervise composing processes as part of their activity; in fully automated distributed applications, in which all exterior interactions are managed by communicating with automated entities, the user role is played by the DIA operator, as he is competent in describing desired functions; in systems that include human interaction, the users are distinguished by their actions, hierarchical and operational position in the organization, security access and profession, as they are relied upon in identifying the needs that are to be addressed by the development of the DIA;  executive and management operatives in organizations and developing companies, as the decisions they take in budgeting and organizing the covering of lacking functionalities impacts on the format and technologies used in the building of the distributed application as well as inducing or eliminating development risks; the organizing of teams and intermediation of their interactions is a factor in the evolution of the application and quality of implementation; project management is responsible with assigning the financial, technical and human resources throughout the analysis, design and development stages, as well as with evaluating and reporting progress;  business analysts, tasked with interfacing between users and design teams and determining the nature, order, impact of user activities, as well as the formatting and validation of requirements for information operated upon; documentation composed at this step serves as future reference in the development of the functional test scenarios, as well as in determining the degree of fidelity between DIA component behavior and initial requirements.Dealing with the usage of software structures, concepts and technologies that define distributed application entities, activities and interactions, as well as with the preliminary testing of the functionalities and subsequent treatment of technical or logical errors, developers rely on functional specifications and design documentation in building the components as well as defining the structures and formats in communication, security and user management through the distributed application.Web-based component of the MERICS system, includes wizards that, upon successful authentication and access rights assessment, guide the user in the choosing of study items, options and parameters of the methods, associated to description paragraphs that inform on the semantics of each possible action; upon computation of the results, they are shown together with information of selected method arguments; if the operation or multimedia content allows it, it is visually represented in both initial form and highlighting the differences; the user is allowed the option of retracing its steps, modifying parameters and resubmitting requests, yet while ensuring that he has specified all the prerequisites; considerations in the design of graphical user interfaces also relate to the level of technical knowledge on the DIA domain of activity that interacting persons possess, as well as their cultural background, with differences in languages used in labels and user messages, mirroring, order of controls and description of operations;  service layer programming, which results in the building of the automated interface components that interact with the exterior through messages containing operational data packages, as well as meta-data on the session and emitter identity; configuration files, records and preprogrammed functions describe the rules of the exchange, techniques for encrypting the operational information and message, as well as the data structures that form the basis in the description of methods and objectives; developer responsibilities are linked to ensuring the optimum usage of communication endpoints, limiting the number of interactions by grouping of data in predetermined structures, caching information that is frequently used in order to reduce processing time and message size, validating the input in format and content, managing the logical layer interactions, programming the tools required in service authentication, cryptographic processes and credential exchange; MERICS implements decoupling in algorithm specifications and content; method parameters or services do not include image or frame content, which is stored in the database and referred through session and file identifiers;  logic and control component construction, done through the description of parameters and implementing of algorithms that manage projected user activities and processes; this development layer contains the highest variance in technologies, frameworks and programming paradigms, which make its components vulnerable to quality-related discrepancies [5] between the projected and implemented operational behavior; in order to address these risks, programming activity is managed by using assemblies and packages that provide structural clarity, diminish redundancy and resources spent, as well as crosscomponent dependency; in large projects or development teams, there occur instances in which the programming team's activity is limited to one such role DOI: 10.12948/issn14531305/17.2.2013.13building communication components, business objects hierarchies;  persistence structures development, with the building of database objects, stored procedures and functions, triggers, indexes, auditing tools, database communication endpoints, as well as overlapping constructs that manage logical layer interactions and provision for objectrelational translations in data structures; MERICS decouples analytical from operational content storage and processing, with database-level exchanges limited to asynchronous processes, which offer the advantage of scheduling in intervals with limited processing strain on the system; developers are required to structure information and implement database schemas partially based on the composition of higher-level entities such as objects and attributes in programming constructs, which relate to tables and columns; they include mapping, communication and archiving functions in assemblies that encapsulate databases in an architectural representation and provide the formatting needed in translating from logical layer to database objects.The development teams are the first to test the new functionalities, as debugging and scenarios described in the specifications serve the elimination of software errors and the detection of behavior unpredicted or unaccounted for in earlier stages, such as computation delays.Developers are responsible for acting on the feedback that testing teams and users provide in order to repair malfunctioning components and reduce processing resource usage discrepancies, optimizing the behavior of the distributed application and providing insight on the technical elements that positively or negatively affect the way in which applications respond to requests.Extensions and modifications on the distributed application, decided at later stages during its life due to moral usage, changes in organization activity, support platforms and technologies or due to requests for the integration of new features [6], are done by retracing the preliminary steps including development.

DIA Security
The Oxford English Dictionary defines risk [7] as a situation involving exposure to danger, the possibility that something unpleasant or unwelcome will happen, a person or thing regarded as a threat or likely source of danger, a possibility of harm or damage against which something is insured, a person or thing regarded as likely to turn out well or badly in a particular context, the possibility of financial loss.Risks relate to concepts in the Probability Theory by the implicit association to the probability of occurrence for these undesirable events, and by the usage of the latter's concepts and functions in analyzing deterministic or random processes.The frequency of occurrence, the approximation or precise determination of damage and resulting recovery costs, as well as the context in which the loss-causing events take place are factors included in classifying IT risks.Risks define probabilities of occurrence for events resulting in losses to the quality of information, operations and budgets for operating parties.DIA analysis is to be included in their assessment, although effects are only observed in later stages or final version of the distributed application.The evaluation of needs, funding, interacting actors, management decisions play a role in the frequency and relevance of incidents [8].Due to the absence of specifications and generic approach that parties have in addressing the form of the final product, this stage is prone to the appearance of qualitative risks, as defined in the subjectively valued effects they trigger:  the lack of inter-department communication in the company or organization that serves as the DIA beneficiary, due to insufficient knowledge dissemination, differences in areas of activity, order of interaction in DOI: 10.12948/issn14531305/17.2.2013.13 the functional use cases that form the activity domain for the entire group, lack of ethical codes, limits on their ability to disclose information, resulting in the insufficient detailing of business structures and methods; a complete application domain related mapping of cross-organization responsibilities and procedures are required in order to aggregate functions; in citizen-oriented egovernment portals, the specifics of each operation designed are detailed by the public organization that uses them, yet the cross-platform communication and person information specifics are shared;  the inability of users to specify the desired functions that the application should perform in helping with their activity, due to the specialization and lack of general knowledge of impact on the organization; sales and accounting, or human resources are areas with limited overview on processes through the company; on the other hand, executive positions do not know the details of the activities that require modifications or extensions; design in social networking and messaging, publically available to non-technical personnel, is driven by generic user requirements or feedbackan individual wish to communicate, acquire information and share details inside networks, without specifying details on authentication, interface design, communication and encryption or logic and operations control;  the unavailability of performance estimators for the system in its incipient stages [1], with impact on the overall performance and development, as lack of processing speed and memory causes vulnerabilities to denial-of-service attacks later on, or impacts the productivity of other applications accessed through the same deployment platform; overextending functions, database size or structure without the corresponding increase in processing leads to slow performance and errors due to synchronous process timeouts; MERICS implements threading and delegation of tasks in order to minimize impact on individual components.Today's most popular approaches to software development are Software as a Service and On-Demand.Differences between the two approaches originate in the perception that the pooling of resources and income generating from the selling of license rights constitutes a superior business approach to the latter, which describes software development as being triggered by the customer.The budget composition for the design and development of a software application is oriented towards the completion of the following tasks:  funding the contractual obligations, in case the developer and user of the application represent different organizations; as delays in payment lead to operational impediments on the part of the latter, the lack of resources dedicated to implementing the application cause delays and the lowering of quality as software and documentation expenses are not manageable and vary [9]; the availability of resources and scale when compared to the company and distributed application size influence the prioritizing of development tasks and environment structure as well as availability of software and hardware;  acquisition of licenses for using software platforms, requiring the identification of user roles and numbers, as well as the proprietary rights that are needed in order to operate with the distributed application; costs introduced by these reflect on the productivity requirements for the developers Determining the development and usage budget of a distributed application impacts the efficiency and quality of the solution, security and operational risk management and software constructs, hardware used for development and testing, as well as the number and technical quality of implementation teams.Maintenance tasks and administration funds affect the incident response times and backup capabilities, as higher amounts allocated to these tasks ensure the acquisition of auditing tools and personnel that interact in order to quickly and safely eliminate the negative effects.

Security Processes and Constructs
Defining the operational requirements that constitute the basis in DIA development constitutes the first step in the formalization of data and behavior structures that characterize a software system.Assigned to the interaction between business and system analysts, users and decision factors, this stage results in the completion of documentation that describe the items that need to be constructed in order to facilitate the beforementioned user activities.As parties pool their resources together, the improper identification of business requirements and logic behind leads to:  increased development time and subsequent costs, as discrepancies between projected and obtained outcomes are tracked to the analysis and reevaluated, with the involvement of each actor in the stages that the DIA has passed through; if an application targeting online messaging fails to provide the users with a message querying function, the feature's translation into data structures, auditing, performance impact, communication strain need to be expressed and evaluated, access rights granted for the user roles to which the operation is relevant and testing for bugs and erroneous behavior conducted; DOI: 10.12948/issn14531305/17.2.2013.13 lowering of result relevancy, as the improper or incomplete mapping of activities to data structures and functions causes the diminishing of report relevancy, inability to project the evolution of factors, through data mining and business intelligence operations, allowance of unstructured data or invalid formats into the operational database; if a financial application's interface module fail to verify for the presence and correctness of a customer's income and address information, querying and reports on location-income correlations are irrelevant, or underperforming at best;  quality losses in the outcome of the application, due to the improper evaluation and attaining of the potential for activity optimizing through DIA operations; customers and users are often unaware of industry best practices in their field or the extent to which their workload is reduced by the implementation of software constructs; alternatively, they do not know or envision in detail the interactions that take place between the departments in an organization, tending to focus on their own tasks; specialization and separation of resources are advantages in productivity improvement, yet rely on the presence and optimal functioning of coordinating elements and teams; using their experience in previous projects, developers are able to direct the customers towards the proper format; in a bank, if a marketing officer does not know or take interest in the relevancy of primary data compiled into the reports he or she constructs through application features, the developer is able to ensure on the data quality by imposing validation on the activity of the branch operator.Processes underlying distributed application operations are characterized by the interaction with tasks, exterior applications and users and the order of precedence for the elements that compose them.Figure 1 plays the role of a test scenario in describing the activity sequence for the enrollment of a financial operation applicant's information.The 4 swim-lanes describe the Customer, Operator, DIA and exterior system roles.As observable, the order of the data being served as input, validation performed and outcome decisions, as well as the outcome depend on the interactions and order of the steps.If the exterior system is called ahead of the validation of identification data and it proves to be inaccurate or incorrect, resources are spent on processing and payment for the service without the accountability of the output, as data return will pinpoint the error, inaccurately describe the result or the answer does not reflect the reality.If the address is not correctly copied or stored together with electronic copies of the customer identification documents, the contract signed at the completion of the task is not valid and therefore legally binding for any of the two parties.The previous scenario allows for the identification of vulnerabilities in the definition of processes for distributed applications:  improper identification of the order of actions underlying the cross-application interactions; the users and business analysts are responsible with the specifying and documenting of the process interactions;  resource spending and cost increase due to redundant or inaccurate messaging and computation definition, as well as improperly secured information design that allows for data theft and interaction, leading to the expense-generating unauthorized usage of application functions and decrease of analysis relevancy by the contamination of data repositories; Using discrete values that specify the degree of compliance with the specified properties, as well as the constraint of assigning unique values, allow for the building of qualitative models that avoid subjective valuing within predetermined ranges, therefore serving to increasing the relevancy of the study.5 invalid or incomplete answers were eliminated from the operations related to the processing of the questionnaire's answers, structured as presented in Table 1.Limiting the extent of confidential information that is sent or received as part of operations 12 Ensuring autonomy for the modules and applications that compose the distributed system 13 The updating of contextual processes and products 14 Risk assessment and incident recovery budgeting 15 Procedural norms regarding the decoupling of environments and related -information The correlation between the priority assigned to a given process or DIA property and associated weights is presented in Table 2.The questionnaire's content and the reasoning behind the choosing of the 15 processes or properties is detailed in the following sections.In order to minimize the influence on the manner in which respondents prioritized their DIA development aspects assessment, the questions were presented in a random order, as pertaining to the subject area.

a. Minimizing operational logic in interface
elements refers the practice of separating the graphical user interface from operational logic, such as formulas, complex validation rules, enquiries that require the interaction with stored information.Advantages of this approach, alongside the clear structuring of the modules comprising the distributed application, include limiting the system's susceptibility to brute force attacks and hiding the implementation details from being reflected in the structure of thepotentially publicinterfaces.On the other hand, development practices aimed at optimizing resource consumption and response times require that information be validated as soon as possible.User interfaces contain validation constructs such as regular expressions that provide the first level of information quality control.b.Ensuring backup for stored information is a wide-spread and critical approach to managing risk.Depending on the nature of the system, however, details regarding the frequency and extent of stored information are required in order to assess its relevancy and the extent of This information serves in composing a graph of -element links, as specified or obtained through operational analysis, with the purpose of determining the influence of security factors and the assessment of weights used in evaluating incident impact.
The following model details on the graph composing methods.
Let be the collection of graph nodes, corresponding to the studied properties or processes.Let describe the collection of arcs formed by the bidirectional links between elements of in the graph.'s elements take the form where is the source node and represents the destination node.

Let
, be a digraph, where denotes the maximum number of arc pairs, members of collection , linking elements of , allowed in the computing of process influence, and having nodes.

Fig. 2. Digraph
The rules used in assigning the arcs are: -all factors are represented; -the digraph is finished when any present node has a maximum of arc pairs assigned; if isolated nodes or sections remain, the model is not relevant for the restriction chosen and the latter must be increased; -the frequency scores assigned as per the methodology presented in table 3 are ordered in a decreasing manner; -corresponding arcs are drawn, keeping the restriction of arcs; -in case more than arcs have a given mode as source or destination, the ones corresponding to the highest frequencies are kept; -if the scores of two or more candidate arcs are identical for the last remaining position, the total score for the respective node is calculated based on the formula: DOI: 10.12948/issn14531305/17.2.2013.13 where represents the score for arc .If the scores of two or more arcs are equal, the arcs are kept and the scores of destination nodes are evaluated, as completed until the current step, or by a post-evaluation if no maximum score is obtained, until a differentiating criteria is computed.The arc that leads to the highest scoring area is kept; -the nodes remaining with an incomplete number of arcs, due to the assignment of all possible positions for source nodes, are left in their current state, as shown in Figure 2 for nodes and .Once the graph is completed, the effect of one factor on the others in the collection is reflected by the computation of a maximum frequency or weight sum, reflecting the manner in which they are linked, as shown by the formula where -score for arc .
The arc scores reflect, alternatively, weights of incident impact factors in DIA components or the product between the frequency of successive hierarchy positions and the measured incident occurrence effects.
Through increasing the number of maximum arcs allowed for each node, factors that influence the analyzed processes are identified.
In the maximal version, in which , a complete and symmetrical digraph is obtained, in which each node is linked to all remaining ones in the collection.The road between any two nodes has the length of 1, with the sum associated to the arcs determining the direct or indirect influence on all others.

Conclusions
The paper presents a model for evaluating the influence of security factors in DIAs, as well as assessing the effects or the impact that users assign to them.The questionnaire's target respondents were chosen with the aim of homogenizing the primary, unfiltered information, which has its format validated as part of the ulterior steps in the procedure.
The composing of the form used for the study included separating these factors or properties, as well as avoiding presenting them in a biased order, which could serve as a suggestion.Not grouping them in subcategories served the same purpose.Imposing a ranking system of assessment allows for the minimization of random choice or evaluation on behalf of the respondents.The further improving of the DIA risk assessment study through a semantic approach has the potential of helping identify and measure in a qualitative spectrum the factors that lead to damage, through the composing of patterns in user activities or DIA module response.Comparability of the primary information is ensured through its aggregation, while keeping individual sets of answers, and by its submission to the same set of refining stages.The methodology built for DIA security influencing factors analysis is applicable to every answer grouping in the study sub-set.Assigned weights are stable and available for all application classes only if statistical testing reveals the constant character of answers, this feature being reflected through the building of homogenous sample groups

Table 1 .
DIA development featuresNo.Order the following security characteristics based on criteria related to the extent of their usage or implementation in distributed applications you have interacted with: 13I: 10.12948/issn14531305/17.2.2013.13Thequestionnaire is structured as follows:

Table 3 .
Frequency of consecutive answers