Recenzovaný vědecký časopis / Peer

Transkript

Recenzovaný vědecký časopis / Peer-reviewed scientific journal
Ročník / Year: 2013
Číslo / Number: 1
ISSN: 1805-4951
Vydává / Publisher:
Vysoká škola ekonomická v Praze / University of Economics Prague
Ročník / Year: 2013 (vychází dvakrát ročně / published twice a year)
Číslo / Number: 1
Místo vydání / Place of edition: Praha
ISSN 1805-4951
Vydává / Publisher:
Vysoká škola ekonomická v Praze / University of Economics Prague
nám. W. Churchilla 4
130 67 Praha 3
Czech Republic (The European Union)
IČ / ID: 61384399
Web: http://aip.vse.cz
Kontakt a technické informace / Contact and technical information:
Václav Řezníček – [email protected]
Zdeněk Smutný – [email protected]
Redakční rada / Board of editors:
Stanislava Mildeová1 | University of Economics Prague, Czech Republic
Martin Boháček | University of Economics Prague, Czech Republic
Tomáš Bruckner | University of Economics Prague, Czech Republic
Vesna Čančer | University of Maribor, Slovenia
Rasa Daugėlienė | Kaunas University of Technology, Lithuania
Jiří Fišer | Jan Evangelista Purkyne University in Ústí nad Labem, Czech Republic
Milan Houška | Czech University of Life Sciences Prague, Czech Republic
Miloslav Hub | University of Pardubice, Czech Republic
Petr Kučera | Komix, Prague, Czech Republic
Petr Máša | Partners Financial Services, Prague, Czech Republic
Jan Ministr | VSB-Technical University of Ostrava, Czech Republic
Eve Mitleton-Kelly | London School of Economics, United Kingdom
Ingeborg Němcová | University of Economics Prague, Czech Republic
Jan Rauch | University of Economics Prague, Czech Republic
Václav Řezníček | University of Economics Prague, Czech Republic
Markus Schwaninger | University of St. Gallen, Switzerland
Antonín Slabý | University of Hradec Králové, Czech Republic
Zdeněk Smutný | University of Economics Prague, Czech Republic
Olga Štěpánková | Czech Technical University in Prague, Czech Republic
Prokop Toman | Czech University of Life Sciences Prague, Czech Republic
Milan Turčáni | Constantine the Philosopher University in Nitra, Slovakia
Viktor Vojtko | University of South Bohemia in České Budějovice, Czech Republic
Jan Voráček | College of Polytechnics Jihlava, Czech Republic
1
Šéfredaktorka / Editor in Chief
OBSAH / CONTENT:
Recenzované stati / Peer-reviewed papers
A Transitive Recommendation System for Information Technology Communities ................ 1
Waleed M. Al-Adrousy, Hesham A. Ali, Taher T. Hamza
Approaching Retargetable Static, Dynamic, and Hybrid Executable-Code Analysis ............ 18
Jakub Křoustek, Dušan Kolář
The adolescence of electronic health records:
Status and perspectives for large scale implementation ......................................................... 30
Stefan Sauermann, Matthias Frohner, Philipp Urbauer, Mathias Forjan,
Birgit Pohn, Andreas Drauschke, Alexander Mense
Vplyv sofistikovaného hybridného Honeypotu na efektivitu architektúry systému
detekcie prieniku v distribuovaných počítačových systémoch............................................... 39
/ Influence of Sophisticated Hybrid Honeypot on Efficiency of Intrusion Detection System
Architecture in Distributed Computer Systems
Peter Fanfara, Martin Chovanec
Vizuální jazyk Archimate pro modelování Enterprise architektury
na příkladu integrace ekosystému tabletu............................................................................... 57
/ Visual language Archimate for Enterprise Architecture modelling
– an example of a tablet ecosystem integration
Hynek Stehlík
Jak žáci a učitelé českých škol využívají Internet .................................................................. 70
/ How Czech Students and Teachers use the Internet
Václav Nádvorník
Viacjadrová architektúra zameraná na akceleráciu výpočtov ................................................ 79
/ Acceleration based on multicore architecture
Liberios Vokorokos, Eva Chovancová
Uplatnění systémového myšlení v analytické fázi vývoje aplikací ........................................ 91
/ Applying systems thinking in the analytical stage of application development
Anna Exnarová
Optimalizácia monitorovania sieťovej prevádzky ................................................................ 101
/ Optimization of Network Traffic Monitoring
František Jakab, Adrián Pekár, Peter Feciľak, Miroslav Michalko
Knižní recenze / Book reviews
Sociální inženýrství aneb umění klamu ................................................................................ 122
/ Social engineering or the art of deception
Tomáš Klíma
Zamyšlení / Reflections
Relativita poznání jako východisko uvažování .................................................................... 125
/ Relativity of knowledge as basis of thinking
Martin Sova
Acta Informatica Pragensia
2(1), 2013, 1–17, DOI: 10.18267/j.aip.9
Online: aip.vse.cz
Section:
Peer-reviewed papers
A Transitive Recommendation System for Information
Technology Communities
Waleed M. Al-Adrousy1, Hesham A. Ali2, Taher T. Hamza1
1
Department of Computer Science, Faculty of Computers and Information
Mansoura University, Egypt
2 Department of Computer Engineering and Systems, Faculty of Engineering
Mansoura University, Egypt
{waleed_m_m, h_arafat_ali}@mans.edu.eg, [email protected]
Abstract: Social networks have become a new trend for research among computer
scientist around the world. Social network had an impact on users' way of life. One
of social network usages is recommendation systems. The need of recommendation
systems is arising when users try to know best choice for them in many items types
(books, experts, locations, technologies, etc.). The problem is that a single person
can't try all alternatives in all possibilities life goals to compare. Thus, a person has
to use his friends' expertise to select better option in any item category. This
process is the main idea of “Recommendation Systems”. Recommendation systems
usually depend on users-to-items ratings in a network (graph). Two main
challenges for recommendation systems are accuracy of recommendation and
computation size. The main objective of this paper is to introduce a suggested
technique for transitive recommendation system based on users' collaborative
ratings, and also to balance loading of computation. All this has to be applied on a
special type of social network. Our work studied the transitivity usage in
connections to get a relation (path) as a recommendation for nodes not directly
connected. The target social network has eight types of nodes. So, there are
techniques that are not suitable to this complex type of network. Those we can
present a new support for recommending items of several types to users with
several types. We believe that this functionality hasn't been fully provided
elsewhere. We have suggested using single source shortest path algorithm
combined with Map Reduce technique, and mathematically deduced that we have a
speeding up of algorithm by 10% approximately. Our testing results shows an
accuracy of 89% and false rejection of 99% compared to traditional algorithms
with less configuration parameters and more steady count of recommendations.
Keywords: Social network, Recommender systems, Collaborative filtering,
Parallelism, Web mining, Graph theory
2
Al-Adrousy, Ali, Hamza
1 INTRODUCTION
Social networks become one of human communications media. In social networks, users communicate
to their friends using modern web 2.0 technologies. Each user can have many friends and in turn each
friend can have many friends, so the transitive nature between users can lead to a Friend-of-a-Friend
relationship (FoaF). Social networks environment encouraged the development of a trend called
“Recommendation Systems”, this trend aims to recommend the best item of interest to a specific user
based on his friends or his FoaF's recommendations – sometimes called “ratings”. The
recommendation systems themselves usually depend on social network and users' interactions with
themselves and with other items (books, articles, code snippets, etc.). Usually those interactions can be
stored in a log file or database. Sometimes, not all recommendations are trust worthy so a process of
Collaborative Filtering (CF) is applied to remove anomalies of recommendations. According to [1],
CF tries to identify users that have relevant interests and preferences by calculating similarities among
user profiles. Recommender systems have several challenges [16]:
Accuracy of suggestion (recommendation), which measures how much similar the suggested items to
user to his/her preferences.
1. Traceability, which means that system can present good reasons to user to know why the
suggested items are selected. This should be presented in user-friendly way.
2. Timely calculation: whatever the techniques applied in recommendation systems, they should
operate in a fast way for both users and server sakes.
3. Load balancing for huge calculations processes. This point can lead also to achieve the timely
calculation goal (3rd point).
In this research, we are interested in 1st and 4th points (accuracy and load balancing). However, we add
an extra dimension to the first point, which is to get the transitive relationships between nodes which
are not directly connected. According to [16], there are several types of recommendation systems:
1. Rank-based recommendation: that's to calculate score for each item, and order items by it.
This is similar to web ranking. Examples for these techniques are Tensor factorization and
FolkRank [16].
2. Content-based recommendation: some semantic analysis is applied to content, meta-data or
description of each item and then recommendation is calculated to measure how similar the
item to each user profile.
3. User-based recommendation, that's to use other friends (or similar users) experts and get their
suggestions.
Our work is focused on 3rd type of recommendation (user-based). This paper is organized as follows;
some background and similar work are presented in section 2. The suggested technique is presented at
section 3, with some mathematical analysis for algorithm speedup. In section 4, testing results and
metrics are presented, and finally section 5 is the conclusion.
3
2 RELATED WORK
There are some common problems in researches about recommender systems [24]; prediction
accuracy, testing opinions' subjectivity, recommended items suitability rather than being high ranked,
effective preferences inference, trust formation of recommended items and usability of recommender
systems interface layout. Those problems focus on the value of the recommended items rather than the
performance of recommendation process itself. Recommender systems had many forms over the few
past years. Some expert systems such as "Syskill & Webert" and Web Browser Intelligence (WBI)
[25] applied intelligence to learn user preferences and patterns of recommendations and decision trees.
This system allowed user to make symbolic ratings about items using words like cold or hot. The
symbolic ratings were converted later by the system into numeric ratings [26]. Numeric rating aimed
to handle the problem of difference in modeling nature between the human view and machine the
view. However, this approach used explicit user likeness actions where user selects the rating for the
item. Another technique in recommender systems was modeling of general interests was the analysis
of user's navigation actions items pages. Also, another set of techniques is to use geographic location
as a measure in recommendation systems for similarity, a good survey about this set is listed in [31].
Knowledge based filtering was discussed in the work of Bruke et al. [27]. Their work classified
knowledge into three areas: the social knowledge about users' database, the individual knowledge
about a particular user and content knowledge about the items in the network. They discussed some
problems in knowledge based filtering such as the distribution of users to items. In that problem, few
items gain the attention of users while some other good items may not discovered.
Some techniques of natural language processing and semantic analysis have been used in some
researches such as the work of Santos and Boticario [28]. In that research a new concept of Semantic
Educational Recommender Systems "SERS" was introduced to join e-learning with semantic analysis.
In [29] a survey is introduced to explore the features of some social networks that include e-learning
support. One of those discussed networks is "OpenStudy" which was a large social learning
community.
Many researchers have studied social networks containing two types of nodes (bipartite graphs), such
as users-to-items relationships. Items can be anything; products, videos or articles...etc. We shall
present two families of related work: suggestion accuracy and Map Reduce application. Each of them
is applied for network graphs. Sometimes those graphs are randomly generated with simulation rules
while other researchers have used a real data set to test their work.
Firstly, for accuracy: According to [9, 10, 11, 12, 30], there are some researches to solve sparsity and
cold-start problem. Ceylan and Birturk [19] have focused on semantic similarity calculation using
three types of similarities; taxonomy (ontology analysis), relation and attributes. They made two
predictors for ratings stored in a matrix. They suggested two models; SEMCBF (content based) and
SEMCBCF (content and collaborative analysis). They could get a precision of about 63 and recall of
range 92-93 approximately [19]. On the other hand, Purtell and his team [20] have developed a greedy
algorithm for constructing social topologies from users' groups’ communications data. Their work
aimed to analyze emails and photo tags from users' profiles to build general information about social
network. They applied their work on a collection of 1,995 email archives and 286,038 tagged photos
4
from Facebook website [20]. Some data mining techniques have been used for dimensionality
reduction like Singular Value Decomposition (SVD) [13, 23]. By applying SVD, user-item rating
matrix sparsity is reduced. Other researchers have used the semantic analysis of social content [14].
Another research technique was to use control theory and dynamics [15]. Papagelis and his team [1]
suggested a technique in section 3 to use trust inference and user similarities estimation. They used
Pearson co-relation to calculate recommendation for items. They also discussed the use of user
similarities to enhance the recommendation.
Secondly, for Map Reduce with graphs: Ekanayake et al. have made [32] a good survey on applying
Map Reduce for data intensive analysis. Morales and his team [21] have addressed the problem of
social content matching using Map Reduce to handle very large data sets. Their algorithms (StackMR
and GreedyMR) are tested on large data sets [21]. Both algorithms scale extremely well. However,
StackMR requires only a poly-logarithmic number of Map Reduce steps, making it an attractive option
for applications with very large data sets. Some other surveys were made in [17, 33, 34] about map
reduce for parallel data processing.
Most of above work either focus on data mining side of computation, or the distributed computation
mechanism. We combine both of them besides studying the multi-mode graph to get transitive
recommendations for far away items.
2.1 CONTRIBUTION
In this paper we focus on a special case of graph of multi-type nodes, k-partite graph. To be specific
we targeted an eight-partite network introduced in the following section. One importance of this eightpartite is the relation between the university sciences and real life career. Our work is focused on two
major targets: parallelism of computation, and accuracy of suggestions. This paper suggests different
technique for calculating recommendation rating queried by a user about an item. The technique of
Map Reduce is suggested for load balancing. The algorithm of single source shortest paths is
suggested to be used with combination with hierarchical clustering. Our work is tested in two parts;
the first part is a mathematical part for Map Reduce effect, we concluded that we have a speeding up
of algorithm by 10% approximately. The second part was a simulation testing for accuracy of
suggestion. Our testing results for that part shows an accuracy of 89% and false rejection of 99%
compared to traditional recommendation systems algorithms with less configuration parameters and
more steady count of recommendations. We can claim that our work uniqueness is the combination of
recommendation systems, Map Reduce, and academic learning co-relation with real life careers using
eight-partite graph. An additional contribution is combining the previous goals with the ability to get
transitive recommendations for items recommended by people not directly connected to starting user's
friends. The nature of single source shortest path algorithms enabled that functionality.
3 SUGGESTED APPROACH
As we introduced in section 2, Papagelis and his team [1] suggested a technique in their paper (section
3) to use trust inference and user similarities estimation. This work is our start and we suggest using
single source shortest pass algorithms to get a strongest relation of nodes in less time. We shall focus
on Bellman-Ford [2, 3] algorithm applied on clustering results.
3.1
5
PROBLEM MODEL
Our main concern is based on a need for a broader range social networks, not just two-mode networks,
but also multi-mode networks. In practice there is a relationships in information technology
communities between many elements, we would focus on eight types of nodes: developers, users,
technologies, reusable components, version control repositories, students, educational courses and
companies. Figure 1 presents an overall relations graph between those elements. In Figure1 there's a
symbol letter beside the name of each node (Element) to be used later in discussion, Each element has
different view: Developers set (D) want to get best reusable components tested and documented and
technologies set (T) for long term projects. Also, they may want to know which courses are best to get
trained on to be up-to-date. Also, Companies want to hire the best developers, either for long or short
term hiring. Or even to know which developer is good to use for outsourcing. Also, companies want to
follow the trends of new technologies and have a decision when to migrate to a new technology.
Students set (S) want to learn new technologies and be up-to-date, and in the same time have a clear
vision which academic educational courses are useful to their study. Users set (U) want to use or buy
the best Products set (P) and have an advice from a friend which product is trusted. Courses
Curricula set (C) need to be updated quickly to provide market needs. Reusable Components and
libraries set (L) already have version control repositories set (R). Those repositories have some
useful data in their log, like frequency of updates, passed unit tests, quality assurance history and so
on. Those data are important to estimate the quality of a product, but they aren't understood by regular
users. So, if there's a simple understood measure of quality to users based upon quality nature, so more
trust can be achieved.
Fig. 1. Overall graph of relations nature between nodes.
According to relationships, there are three types of relationships: Trust relation (which is between
humans and each other). Usage relation (which is between an item and its user). Recommendation
relation (which is a higher degree of usage that has a degree of satisfaction). The social network itself
6
can be modeled as a large graph G(V,E), Where ∈ ,
∪ ∪ ∪ ∪ ∪ ∪ ∪
,∧ ∃ ∈ ,
∣ ∣∈ . Usually, Social network edges values are limited to small set of integer
values like set [1, 5] to express strength of relation between edge ends. Sometimes, some social
networks express (Dislike) relation in negative values. There are some examples of applications in
this large graph: Recommendation of products (P) to customers U (direct relation), recommendation of
courses C to students S (direct relation), recommendation of courses C to students S though
technologies (Indirect relation by filtering the direct relations between C and S), recommendation of
Market trends U to students S though technologies T, products P, libraries L and so on. An important
aspect is to get a relation between nodes not directly connected or not even from the same type or
cluster. For example, to get a recommendation for students to learn new technologies based on the
popularity of products developed by that technology.
3.2 PRELIMINARIES
3.2.1
BELLMAN-FORD ALGORITHM
Bellman–Ford runs in O(V·E) time [2], where V and E are the number of vertices and edges
respectively. The Bellman-Ford algorithm determines the shortest path from the source s to each v in V
for a graph G = (V; E) with real-valued weights, which may be negative. This point is important in
case of expressing dislike operations in social network, which would result in negative edges between
a user and an item. The algorithm assigns each vertex v in V its correct shortest path weight, provided
there are no cycles with negative weights. The algorithm then returns true if and only if there are no
negative weight cycles. The algorithm is described in Listing 1.
procedure Bellman Ford(list vertices, list edges, vertex source)
// This implementation takes in a graph, represented as lists of vertices
// and edges, and modifies the vertices so that their distance and
// predecessor attributes store the shortest paths.
// Step 1: initialize graph
for each vertex v in vertices:
if v is source then v.distance := 0
else v.distance := infinity
v.predecessor := null
// Step 2: relax edges repeatedly
for i from 1 to size(vertices)-1:
for each edge uv in edges: // uv is the edge from u to v
u := uv.source
v := uv.destination
if u.distance + uv.weight < v.distance:
v.distance := u.distance + uv.weight
v.predecessor := u
// Step 3: check for negative-weight cycles
for each edge uv in edges:
u := uv.source
v := uv.destination
7
if u.distance + uv.weight < v.distance:
error "Graph contains a negative-weight cycle"
List. 1. Bellman-Ford Algorithm [2, 4].
Bellman-Ford is preferred than another algorithm called Dijkstra shortest path [2, 4] for its complexity
and running time.
3.2.2
SIMILARITY OF SAME-TYPE NODES
As presented in [1], similarity between users can be estimated using the following equation:
∑
,
,
∑
,
∑
,
From [1] the definition for this Pearson correlation uses the following symbols: ux, uy are two friend
users. Items co-rated by both users are subset I={ix, x=1,2,....n}. rux,ih rating of user ux to item ih. rux, ruy
are average ratings by users ux, uy.
3.2.3
MAP REDUCE
As explained in [22, 33, 36], Map Reduce is a parallel and distributed solution approach developed by
Google for processing large data sets. Map Reduce has two key components. Map and Reduce. A map
is a function which is used on a set of input values and calculates a set of key/value pairs. Reduce is a
function which takes these results and applies another function to the result of the map function. The
approach assumes that there are no dependencies between the input data. This makes it easy to
paralyze the problem. Map Reduce depends on forking(Map) a computing over many processing units
and aggregate their results (Reduce) to form final total result [8,17] as shown in figure 2:
8
Fig. 2. Map Reduce Architecture according to [37].
This can reduce overhead on server and reduce calculations time.
3.3 SUGGESTED MAIN ALGORITHM
Instead of relaying only on either trusted friends' recommendations or similar users' recommendations,
we suggest combining both of them in the following way:
Find Recommendations (Multi-Partite_network, partite_count, count of clusters): Complexity Estimation
1.
Consider each node a cluster initially
O(m)
2.
Sort all graph nodes based on hash value
O(m2)
3.
Find proximity matrix by getting all output edges weights for each node.
O(m)
4.
T = partite_count
O(1)
5.
Initialize T of sub-proximity matrices, each matrix is for a set of nodes of same types.
O(m)
6. Parallel For each sub-proximity matrix M
Use Manhattan distance to cluster nodes inside same type sub-graph store the results as
connected components
O(m2 +u) without
parallelism, O(m+u) with
parallelism.
7.
Merge all connected components arrays into a single array.
O(m2)
8.
Create a graph of connected components,
O(1)
9. Let connected components graph edge weights = sum of all common edges between the O(m.u)
nodes of those two components. (edges grouping)
10. Remove weak relations between connected components.
O(u)
11. Apply Hierarchical clustering to cluster connected components as blocks.
O(u.log u)
12. Apply Bellman-ford shortest path calculation on each cluster.
O(u.e)
13. Let Recommendation set for each cluster = cluster neighbor of other types.
O(u)
List. 2. Suggested Algorithm.
9
For edges in graphs, there is a problem; the nature of relationships between nodes differs. Some
relationships that express “trust” can be expressed in range [-5,5]. However, dependency relations
have broader range (like case of libraries and products). So, to unify our calculations we need a
normalization pre-processing. For normalization, we suggest the following equation:
,
,
Where i is the edge with index i, t the type of node, E(i,t) is the original edge weight for edge i, N(i,t) is
the normalized edge i in type t, Max(Et) is the greatest edge weight per same type t. in fact this is not
a perfect normalization, but it's quick for computation. In the algorithm in listing 2, the 6th step is
parallel, which enables the use of Map Reduce algorithm. In the following section, we shall present a
mathematical analysis for the suggested algorithm to get an approximation of computation speedup. In
second column in table in Listing 2, an estimation of each instruction complexity is presented to allow
mathematical analysis in next sub-section.
3.4 PARALLELISM SPEEDUP APPROXIMATION
The speedup of calculation can be estimated by Dahlia’s Law [18]:
1
1
Where p is the percent of parallel code, and n is the number of processing nodes. In fact, this law is
applied in multiprocessing systems originally. Of course, in distributed systems there should be a
consideration for network overhead. However, the Dahlia’s law is a good approximation for speedup.
So in order to calculate the p factor we introduced a mathematical analysis for algorithm individual
instructions in listing 2. First analysis for algorithm without parallelism:
2 3∗
2∗
∗
2∗
∗ log
.
and since u and e are less than m, then:
2
3∗
2∗
10 ∗
, and when algorithm has parallelism:
∗
2∗
∗ log
.
So,
9∗
, Then by dividing the parallelism by linear size, we can say that the
parallelism had a decreased size percentage 0.9 approximately. So the percentage of parallel code (p)
= 1-0.9 = 0.1 approximately. So we can apply Dahlia’s law at p = 0.1 for any number of
multiprocessing cores n.
4 TESTING AND RESULTS
4.1 SIMULATION ENVIRONMENT
Basically, we focused in this paper on testing the accuracy of transitive recommendation which is the
second goal of algorithm. For the first goal (load balancing) we presented a mathematical analysis for
it in sub-section (3.4). in that analysis we concluded that parallelism is effective by 10%
10
approximately. Running tests using JUNG[5] and LingPipe[6] java libraries for eight-partite graph for
several random samples. The following figures show some samples of original testing networks (2
samples with different sizes), shown by figures 3 and 4.
Fig. 3. Sample 1
Fig. 4. Sample 2
In the our experiments, we randomly created graphs, containing eight types of nodes to represent
eight types of objects in target study; students, courses, repositories, technologies, users, developers,
products and reusable components. For simplicity, we've assumed that each type have equivalent
number of items. Figure 3 shows a graph with 10 nodes for each type, while figure 4 shows another
graph with 15 nodes per type. The edges in both graphs are also randomly created within a specified
range for each type. The experiment method tried to compare traditional Collaborative Filtering
techniques described in [1] with our suggested technique, and see how far our suggested algorithm
could reach the same results using single source shortest path algorithm. After clustering both samples
we get the following two connected components graphs shown in figures 5 and 6. The edges between
clusters are the summation of outgoing edges weights in the children of each clustering to the other
cluster children. After that a removal of weak edges is done. The value of threshold is fixed to an
arbitrary value since it's beyond the scope of the current study.
Fig. 5. Clustered Sample 1
11
Fig. 6. Clustering sample 2
To evaluate algorithm we have applied several metrics discussed in the following sub-section to
compare traditional recommender system algorithm with our suggested algorithm.
4.2 USED METRICS OVERVIEW
The used metrics for comparison is based on LingPipe library [6] precision evaluation. The precision
recall evaluation is a matrix of counts of reference (goal) and response (tested) classifications. When
a tested classification contains a target item then the value of the matrix is “true”. Otherwise the
“false” value is stored in matrix. To compare two classification results, the precision matrix is
evaluated first, then iterating over all classes generated in matrix. The ideal target is to have all
classifications sets common in those two matrix and no extra sets in any of them to 100% match.
Table 1 presents all possible combinations between response and reference [6].
Response matrix
Referenc
e matrix
True (found)
False (missing)
Reference
Totals
True
(found)
True Positive
(TP)
False Negative
(FN)
Positive
Reference
False
(missing)
False Positive
(FP)
True Negative
(TN)
Negative
Reference
Positive Response
Negative Response
total
Response Totals
Tab. 1. The relation between a reference and response in precision matrix. [6]
From those cases we can get several statistics [6, 7, 35] presented in Listing 3.
12
1.
2.
3.
4.
5.
6.
7.
8.
∗
9.
,
1
∗ 1
,
where
10.
where:
1
2
and
,
List. 3. Summary of statistics used for evaluation.
In the following sub-section 4.3, a comparison is performed using the previous metrics.
5 EXPERIMENTS RESULTS
Consider the CF algorithm is reference and suggested clustered CF algorithm is response, we
performed several experiments and we got those results.
Measure
AVERAGE
Accuracy
0٫89
Rejection Recall
0٫89
Rejection Precision
0٫99
Random Accuracy
0٫85
Random Accuracy Unbiased
0٫85
kappa
0٫25
Tab. 2. Testing results for comparing basic CF and Clustered CF.
The most important results are: accuracy from table [2] is 89%, and the rejection precision is 99%. So
the, the suggested algorithm is moderate compared to original algorithm. However, Kappa agreement
value is too low. We have an assumption that the too low kappa agreement is resulted due to extra
transitive recommendation inferred by suggested algorithm. The discussion point is: are those extra
13
recommendations really suitable to querying start users? Well, this can't be covered in random
simulation, and has to be tested on real users and get a real feedback to have some sort of supervised
evaluation. Unfortunately, since our suggested eight-partite network is not covered a lot in previous
researches, we didn't find suitable data set to test our algorithm on it. All available data sets are either
same-type nodes with relationships or bi-partite networks (2 types of nodes only).
In order to explore in more detail the existence of extra recommendation by our algorithm compared to
traditional collaborative filtering algorithm [1], we've made another experiment to compare count of
suggested items in both algorithm in traditional recommendation shown in table 3 and Figure 7. Our
experiment was designed to generate random network with fixed number of items per partite. After
that, both traditional recommendation algorithm and our suggested algorithm are applied to the same
network in each case. We've assumed that the traditional algorithm needs parameter k, as number of
maximum recommended items per request. Of course, this parameter has many values, starting from 1
to n in case of network of items. So, in each network test case, we have tested many values for k in
within that range. The values in table 3 are the result of dividing the value of suggested algorithm
average count of recommendation over the traditional algorithm average count of recommendation.
Items per
partite
Maximum recommendation parameter k
1
3
5
7
9
11
13
15
17
19
29
35
43
49
10
10.00 10.00 5.00
5.00
3.30
-
-
-
-
-
-
-
-
-
12
12.00 12.00 6.00
4.00
4.00
4.00
-
-
-
-
-
-
-
-
14
14.00 14.00 7.00
4.66
4.66
3.50
3.50
-
-
-
-
-
-
-
16
16.00 16.00 8.00
5.30
5.30
4.00
4.00
3.20
-
-
-
-
-
-
18
18.00 18.00 9.00
6.00
6.00
4.50
4.50
4.50
3.60
-
-
-
-
-
20
10.00 10.00 5.00
3.30
3.30
2.50
2.50
2.00
2.00
1.60
-
-
-
-
30
10.00 10.00 5.00
3.30
3.30
2.50
2.50
2.00
2.00
1.60
1.40
-
-
-
50
10.00 10.00 5.00
3.30
3.30
2.50
2.50
2.00
2.00
1.60
1.25
1.10 0.91 0.77
100
10.00 10.00 5.00
3.30
3.30
2.50
2.50
2.00
2.00
2.00
2.40
1.10 1.00 0.91
Tab. 3. Matrix of Comparison Ratio.
So, when the comparison ratio is 2.0 for example, it means that our algorithm has produced twice as
traditional algorithm (200%). In fact, our algorithm is steady in the number of items of
recommendation; it produces almost the same count of recommendations and doesn't need extra
parameter of k. In fact it's the same value in column at k=1 in table 3. We assume that is easier for
users who don't want to enter configuration values like k. the dashed values in table 3 means that k
value is not applicable in that case. An interesting result has been noticed, that as more convergent the
value of k to the value of count of items per partite, the more similar count of items produced by the
two algorithms and at some point our algorithm produces less results than the traditional algorithm. To
judge which is more correct, we need a real sample data set with a real feedback of users to get some
14
sort of supervised learning. In figure 7, a curve is made for each sample with fixed count of items per
partite. The curve values themselves are the comparison ratio values defined in table 3.
Fig. 7. Recommendation Ratio Comparison Graph.
6 CONCLUSION
The suggested algorithm is designed for two main goals: load balancing and accuracy. For first goal
(load balancing), it could use parallel loops using Map Reduce technique to get a reduction of
computation size estimated mathematically as 10%. for second goal (accuracy of recommendation), it
achieves 89% accuracy and 99% rejection precision with less configuration parameters and more
steady count of recommendations. The power of the suggested algorithm is in finding association
between k-partite graphs compared to other algorithms which may ignore the nature of k-partite. The
use of Map/reduce is proposed to reduce overhead on server and reduce computation time. The
practical application of suggested algorithm in this paper can achieve the mutual use of distributed
systems algorithms, web mining and graph theory techniques. However, testing results is based on
simulation. We hope that we can apply this in real life and test the suggested algorithm and
architecture when dealing with target eight-partite graph in technology community. Our results show
that the suggested algorithm is a good start but needs more enhancements in the quality of
recommendation. In fact, we have a problem in randomly created samples, that can't confirm or deny
that the suggested algorithm recommendations are really suitable to users, or has some shortage in
some case. Some real test cases and datasets are needed.
15
7 REFERENCES
[1]
PAPAGELIS, M., PLEXOUSAKIS, D., KUTSURAS, T. Alleviating the Sparsity Problem of
Collaborative Filtering Using Trust Inferences. Trust Management, 2005, pp. 224-239.
[2]
CORMEN, T. H., LEISERSO, CH. E., RIVEST, R. L., STEIN, C. Introduction to Algorithms,
Third Edition. The MIT Press, 2009.
[3]
MEGHANATHAN, N. Survey of Topology-based Multicast Routing Protocols for Mobile Ad
hoc Networks, International Journal of Communication Networks and Information Security
(IJCNIS), vol. 3, no. 2, pp. 124–137, 2011.
[4]
JENSEN, J. B., GUTIN, G. The Bellman-Ford-Moore algorithm. Section 2.3.4 in Digraphs:
theory, algorithms and applications. Springer, 2009.
[5]
Jung Library [online]. [cit. 2013-05-21]. URL: http://jung.sf.net/
[6]
LingPipe online documentation [online]. [cit. 2013-05-21]. URL: http://alias-i.com/lingpipe3.9.3/docs/api/com/aliasi/classify/PrecisionRecallEvaluation.html
[7]
CHOI, S. S., Cha, S. H., TAPPERT, C. A survey of binary similarity and distance measures.
Journal of Systemics, Cybernetics and Informatics 8.1, pp. 43-48, 2010.
[8]
JI, CH., BUYYA, R. Mapreduce programming model for. net-based cloud computing. EuroPar 2009 Parallel Processing. Springer Berlin Heidelberg, pp. 417-428, 2009.
[9]
BREESE, J. S., HECKERMAN, D., EMPIRICAL, C. K. Analysis of predictive algorithms for
collaborative ﬁltering. Proceedings of the Fourteenth Conference on Uncertainty in Artificial
Intelligence (UAI-98), San Francisco, Morgan Kaufmann, pp. 43–52,1998.
[10]
MELVILLE, P., MOONEY, R. J., NAGARAJAN, R. Content-boosted collaborative ﬁltering
for improved recommendations. In Proceedings of the Eighteenth National Conference on
Artificial Intelligence, (AAAI/IAAI-02), AAAI Press, Menlo Parc, CA, USA, pp. 187–192,
2002.
[11]
XU, B., BU, J., CHEN, C., CAI, D. An exploration of improving collaborative recommender
systems via user-item subgroups, In Proceedings of the 21st international conference on
World Wide Web - WWW ’12, April 16–20, 2012, Lyon, France, p. 21-30, 2012.
[12]
CEYLAN, U., BIRTURK, A. Combining Feature Weighting and Semantic Similarity Measure
for a Hybrid Movie Recommender System. The 5th SNA-KDD Workshop ’11 (SNA-KDD’11),
August 21, 2011, San Diego CA USA.
[13]
SARWAR, B. M., KARYPIS, G., KONSTAN, J. A., RIEDL, J. T. Application of
dimensionality reduction in recommender systems: A case study. In WebKDD Workshop at
the ACM SIGKKD, 2000.
[14]
JANE, J. Y. L., HSU, Y. J. LEE, T. Y. News Feed Filtering with Explanation Using Textual
Concepts and Social Contacts. The 5th SNA-KDD Workshop ’11 (SNA-KDD’11), San Diego
CA USA, August 21, 2011.
16
[15]
JAMBOR, T., WANG, J., LATHIA, N. Using Control Theory for Stable and Efficient
Recommender Systems. In Proceedings of International World Wide Web Conference
Committee (IW3C2), Lyon, France .April 16–20, 2012.
[16]
MARINHO, L. B., NANOPOULOS, A., THIEME, L. S. Social Tagging Recommender
Systems, chapter in Recommender Systems Handbook, pp. 615–644, 2011.
[17]
LIN, J., SCHATZ, M. Design patterns for efficient graph algorithms in MapReduce.
Proceedings of the Eighth Workshop on Mining and Learning with Graphs. ACM, pp.78-85,
2010.
[18]
DONIS, M. Parallel Programming with Microsoft® Visual Studio® 2010 Step by Step.
Microsoft Press, 2011.
[19]
CELYAN, U., BIRTURK, A. Combining Feature Weighting and Semantic Similarity
Measures for Hybrid Movie Recommender System. The 5th SNA-KDD workshop '11, San
Diego, CA USA, August 2011.
[20]
PURTELL, T. J., MACLEAN, D., KEAT, S. An Algorithm and Analysis of Social Topologies
from Email and Photo Tags. The 5th SNA-KDD workshop '11, San Diego, CA USA, August
2011.
[21]
MORALESM, G. D., GIONIS, A., SOZIO, M. Social Content Matching in Map Reduce. The
37th international conference on very large databaese, Seattle, Washington. AugustSeptember 2011.
[22]
VOGEL, Lars. MapReduce Introduction [online]. [cit. 2013-05-29]. URL:
http://www.vogella.com/articles/MapReduce/article.html
[23]
ZHANG, Y., ZHOU, J., CHENG, J. Preference-Based Top-K Influential Nodes Mining in
Social Networks, in 2011I EEE 10th International Conference on Trust, Security and Privacy
in Computing and Communications, 2011, pp. 1512–1518.
[24]
PU, P., CHEN, L., HU, R. A user-centric evaluation framework for recommender systems.
Proceedings of the ACM RecSys 2010 Workshop on User-Centric Evaluation of Recommender
Systems and Their Interfaces (UCERSTI), Barcelona, Spain, Sep 30, 2010, i, pp. 14–21.
[25]
GOMAH, A., ABDEL-RAHMAN, S., BADR, A., FARAG, I. An Auto-Recommender Based
Intelligent E Learning System. International Journal of Computer Science and Network
Security, 2011, 11, (1), pp. 67-70.
[26]
LOPS, P., DE GEMMIS, M., SEMERARO, G.: Content-based Recommender Systems: State
of the Art and Trends, chapter in: Recommender Systems Handbook (Springer Science and
Business Media, LLC), 2011, pp. 73–105.
[27]
BURKE, R., FELFERNIG, A., GKER, M.: Recommender systems: An overview. AI
Magazine, Association for the Advancement of Artificial Intelligence, 32, (3), pp. 13–18,
2011.
[28]
SANTOS, O., BOTICARIO, J. Requirements for Semantic Educational Recommender
Systems in Formal E-Learning Scenarios. Open access Algorithms, 2011, 4, (2), pp. 131-154.
17
[29]
RAM, A., AI, H., RAM, P., SAHAY, S. Open Social Learning Communities. International
Conference on Web Intelligence, Mining and Semantics, WIMS-11, Sogndal, Norway, May
2011, Article No. 2.
[30]
P. LOPS, DE GEMMIS, M., SEMERARO, G. Content-based Recommender Systems : State
of the Art and Trends, Springer Science and Business Media, LLC, 2011, pp. 73–105.
[31]
DESROSIERS, C., KARYPIS, G. A comprehensive survey of neighborhood-based
recommendation methods, chapter in Recommender Systems Handbook, 2011.
[32]
EKANAYAKE, J., PALLICKARA, S., FOX, G. Mapreduce for data intensive scientific
analyses. eScience, 2008. eScience'08. IEEE Fourth International Conference on. IEEE, 2008.
[33]
LEE, K. H., et al. Parallel data processing with MapReduce: a survey. ACM SIGMOD Record
40.4 (2012): pp.11-20, 2012.
[34]
DELIP, R., YAROWSKY, D. Ranking and semi-supervised classification on large scale
graphs using map-reduce. Proceedings of the 2009 Workshop on Graph-based Methods for
Natural Language Processing. Association for Computational Linguistics, 2009.
[35]
MANNING, C. D., RAGHAVAN, P., SCHÜTZE, H. Introduction to information retrieval.
Vol. 1. Cambridge: Cambridge University Press, 2008.
[36]
DEAN, J., SANJAY, G. MapReduce: simplified data processing on large clusters.
Communications of the ACM 51.1, pp.107-113, 2008.
[37]
Werneck Paiva. [online]. [cit. 2013-04-29]. URL:
http://blog.werneckpaiva.com.br/2011/08/como-funciona-o-map-reduce-usado-pelo-google/
2(1), 2013, 18–29, DOI: 10.18267/j.aip.10
Online: aip.vse.cz
Section:
Approaching Retargetable Static, Dynamic,
and Hybrid Executable-Code Analysis
Jakub Křoustek1, Dušan Kolář1
1
IT4Innovations Centre of Excellence
Faculty of Information Technology
Brno University of Technology
Božetěchova 1/2, 612 66 Brno, Czech Republic
{ikroustek, kolar}@fit.vutbr.cz
Abstract: Program comprehension and reverse engineering are two large domains
of computer science that have one common goal – analysis of existing programs
and understanding their behaviour. In present, methods of source-code analysis are
well established and used in practice by software engineers. On the other hand,
analysis of executable code is a more challenging task that is not fully covered by
existing tools. Furthermore, methods of retargetable executable-code analysis are
rare because of their complexity. In this paper, we present a complex
platform-independent toolchain for executable-code analysis that supports both
static and dynamic analysis. This toolchain, developed within the Lissom project,
exploits several previously designed methods and it can be used for debugging
user’s applications as well as malware analysis, etc. The main contribution of this
paper is to interconnect the existing methods and illustrate their usage on the
real-world scenarios. Furthermore, we introduce a concept of a new retargetable
method – the hybrid analysis. It can eliminate the shortcomings of the static and
dynamic analysis in future.
Keywords: Debugger, Decompiler, Reverse Engineering, Lissom
19
1 INTRODUCTION
As E. W. Dijkstra said years ago: “If debugging is the process of removing bugs, then programming
must be the process of putting them in.”. Moreover, software development is getting more tricky since
applications are being developed for a wide range of target platforms (computers running x86(-64)
processors, smart devices with ARM multi-cores, consumer electronics with smaller chips, etc.) where
the toolchain (e.g. compiler, disassemble, simulator) can be incomplete or not properly tested (e.g.
automatically generated compiler, experimental target-specific optimizations), especially for the newly
created platforms such as application-specific instruction-set processors (ASIPs).
With this diversity of target architectures and operating systems, it is not easy to properly analyze and
debug your code because it is highly probable that the appropriate analytical tool do not support such
particular target platform.
Roughly speaking, analysis of the source code is easier since it is more or less platform independent.
Only the basic information about the target architecture (e.g. bit-width, endianity) is usually enough.
As an example we can mention Coverity SAVE [14] that can be used for retargetable source code
verification. However, there are two major scenarios where source-code analysis cannot be used.
(1) Analysis of applications distributed in the form of executable files (abbreviated as
executables in the following text) without source codes. This kind of analysis is useful for
malware analysis, testing of the third-party commercial software, etc.
(2) Whenever we need to examine executable versions of our own software, e.g. testing
automatically generated compiler used for application’s compilation, validation of the code
optimized after compilation (optimizing linkers, postpass code optimization tools like AbsInt
[5], etc.). Within this analysis, source code is available as well as additional information like
symbols or debugging information.
In the following text, we present a complex retargetable framework for executable-code analysis,
which is capable of both static and dynamic analysis. This framework was successfully implemented
and tested within the Lissom project [10].
The motivation of this paper is to demonstrate both approaches on the real-world scenarios described
in the previous paragraph. Furthermore, we highlight their drawbacks and we present their
enhancement – the hybrid analysis. This approach combines advantages of the current methods but it
is not implemented yet.
The paper is organized as follows. Section 2 discusses the state of the art of executable-code analysis.
The description of the retargetable approach developed within the Lissom project is given in Section 3.
Afterwards, we evaluate our methods of static and dynamic analysis on the real-world scenarios in
Section 4. In Section 5, we introduce a new type of analysis, the hybrid analysis, and examples of its
usage. Finally, Section 6 contains conclusion of this paper and discussion about the future research.
20
Křoustek, Kolář
2 STATE OF THE ART
In this section, we discuss the state of the art of executable-code analysis. In present, we can find
several common executable file formats – UNIX ELF, WinPE, Mac OS-X Mach-O, etc. These files
may contain debugging information in one of the modern existing standards – DWARF or Microsoft
PDB, for more details about theses formats and their processing see [7].
In order to support their accurate and comfortable analysis, it is important to provide appropriate tools.
We can find two basic groups of tools – static and dynamic.
(1) Static executable-code analysis examines applications without their execution and it is usually
focused on the program transformation from a machine code into a human-readable form of
representation. The most common tools are disassemblers, which produce assembly code, or the more
modern decompilers producing a high-level language (HLL) code (C, Java, etc.). Static analysis can
also perform control-flow and data-flow checking, see [6] for more details.
(2) Dynamic analysis executes the application and it analyses its behavior during the run-time. The
execution can be done either on the target architecture (e.g. remote debugging) or via simulation or
emulation. Profilers, simulators, and debuggers are the most often used tools within this category.
The platform-specific analysis of executables is a partially solved problem, because implementation of
such tool is a straightforward task [8, 15]. The existing toolchains usually contain both dynamic and
static tools. For example the GNU Compiler Collection together with the Binutils package contains
a profiler, disassembler, and debugger. Another example is the Microsoft Visual Studio. Nevertheless,
program decompilation is still rare because even platform-dependent decompilers are hard to create [2,
3].
The retargetable analysis (i.e. the target architecture can be easily changed) is a more challenging task.
We can find several projects focused on a rapid ASIP design that supports quality dynamic analysis
(i.e. simulation and debugging of the ASIP’s applications), but with a very limited static analysis (only
the disassemblers are supported in general). All of these projects exploit its own architecture
description language (ADL), which has been developed within the project, for the toolchain
generation.
For example, the xADL project, developed at the Vienna University of Technology, supports
generation of three types of simulators, but the support of debugging and static-analysis is missing. In
other projects (ArchC, Sim-nML, EXPRESSION, LISA, etc), the situation is very similar – they
support various types of automatically-generated simulators and debuggers, but the static analysis
is very limited [8].
In past, there were only two attempts to create a retargetable decompiler – the PILER
System (1976) [1] and the Boomerang project (2007) [16]. However, none of them was entirely
completed and they are no longer actively developed.
21
3 RETARGETABLE STATIC AND DYNAMIC EXECUTABLE-CODE
ANALYSIS
Our solution is developed as a part of the Lissom project located at Brno University of Technology
[10]. The project is primarily focused on the design and development of the new ASIPs, their
applications, and their interconnection within large Multiprocessor Systems-on-Chips (MPSoC).
A complete toolchain is developed within this project. It is automatically generated based on the target
architecture description. The ISAC architecture description language [10] is used for this purpose.
Each ISAC processor model consists of several parts. In the resource part, processor resources, such as
registers or memories, are declared. In the operation part, processor instruction set with behavior of
instructions is specified. The assembler and coding sections capture the format of instructions in the
assembly and machine language, respectively. Behavior section is used for description of the
instruction semantics via the ANSI C code, see Fig. 1 for illustration.
RESOURCES {
PC REGISTER bit[32] pc;
REGISTER bit[32] gpregs[16];
RAM bit[32] memory {...};
}
//
//
//
//
HW resources
program counter
register file
memory, etc.
// instruction set description
OPERATION op_sub {
INSTANCE gpregs ALIAS {rd, rs, rt};
ASSEMBLER { "SUB" rd "," rs "," rt };
CODING { 0b1111 rs rt rd };
// instruction’s behavior description
BEHAVIOR { regs[rd] = regs[rt] - regs[rs]; }
}
Fig. 1. Example of a simple processor description in the ISAC language.
Size of the ISAC models varies based on the architecture’s complexity; see Tab. 1 several examples.
The RISC (Reduced Instruction Set Computer) architectures (MIPS, ARM, SPARC, etc.) are usually
easier to describe than CISC (Complex Instruction Set Computer), such as Intel x86. ISAC is also
capable to describe VLIW (Very Long Instruction Word) architectures (VEX, ADI Blackfin, etc.) as
well as the highly-parallel architectures like multi-core processors, or multiprocessor systems on chip
(MPSoC) [12].
MIPS ARM VEX x86
Lines of ISAC code
3300 3400 1500 7000
Lines of auxiliary C code 1500 2000 800 2600
Total
4800 5400 2300 9600
Tab. 1. Complexity of the ISAC models for different architecture types.
22
Křoustek, Kolář
The ISAC models are used for an automatic toolchain generation, e.g. C compiler, assembler, and
analytical tools – decompiler, debugger, and simulators, see Fig. 2.
Fig. 2. Tools automatically generated based on the ISAC models.
In present, three main types of simulators are supported – interpreted, compiled, and translated.
The interpreted simulator performs constant fetching, decoding, and executing instructions from
memory. This approach is relatively slow but it is independent on the simulated application. On the
contrary, the compiled simulator is dependent on a particular application because it is generated based
on its content. However, it is faster than the former one because the repetitive tasks (e.g. fetching,
decoding) are pre-computed during simulator creation. Finally, the translated simulator further
enhances the concept of the compiled simulator via usage of debugging information [7]. Based on this
information, we are able to extract information about the basic blocks (BB) contained within the
application. Afterwards, the translated simulator is capable to execute instructions within the same BB
in a burst mode (e.g. it is possible to skip several checks for these instructions). Therefore, its speed is
even higher than the compiled simulator. However, the presence of debugging information
is mandatory in this case.
Each simulator type suites for a different usage, see [12, 13] for details. The debugger allows dynamic
analysis on the different levels (e.g. microarchitecture, instruction level, and source-level) [8]. The
first two levels do not need any additional information, while the source-level debugger needs
debugging information.
The retargetable decompiler is depicted in Fig. 3. At first, the input binary executable is transformed
into an internal COFF representation. Afterwards, such file is processed in the front-end part, which is
partially automatically generated based on the ISAC model. This phase decodes machine-code
instructions into the LLVM IR representation [9], which is used as an internal code representation
of decompiled applications in the remaining decompilation phases. In the middle-end part, this LLVM
IR code is heavily optimized using optimization passes. Finally, the resulting HLL code is emitted in
the back-end part. Currently, the Python-like language and the C language are supported. In present,
the retargetable decompiler allows decompilation of MIPS, ARM, and Intel x86 executables. The
detailed description can be found in [3, 4].
23
Fig. 3. Retargetable decompiler developed within the Lissom project.
4 STATIC AND
SCENARIOS
DYNAMIC
ANALYSIS
IN
A
REAL-WORLD
In this section, we present several scenarios of a retargetable executable-code analysis. We use the
previously described tools for the static and dynamic analysis of these executables.
For evaluation, we use a MIPS architecture that is described using the ISAC language on the
instruction-accurate level. MIPS is a 32-bit RISC processor architecture. The processor description is
based on the MIPS32 Release 2 specification [11].
Several open-source applications and algorithms from benchmarking test-suites were used for testing.
The Minimalist PSPSDK compiler (v 4.3.5) was used for their compilation into the MIPS-ELF
executables. Different versions of optimizations were used. The testing was performed on Intel Core2
Quad with 2.8 GHz, 4 GB RAM running a Linux-based 64-bit operating system. The gcc (v4.6)
compiler with optimizations enabled was used for the creation of all tools.
4.1 ONLY THE EXECUTABLE AVAILABLE
In this situation, we only have a naked (stripped) executable. Neither additional information nor its
source code is available. This is the usual scenario of the third-party-software distribution or malware.
Dynamic analysis can be done using interpreted or compiled simulation. The average speeds
of interpreted and compiled simulators for MIPS are 27MHz and 55MHz, respectively [12].
24
Křoustek, Kolář
In the scenario of the interpreted simulation, the simulator is automatically generated based on the
target architecture model in ISAC (i.e. MIPS model). This simulator is capable to simulate the input
application instruction by instruction. According to the description in Section 3, the compiled
simulator needs to be generated for this particular input file. No additional information (e.g. debugging
information) is necessary for creation and usage of these two simulators.
On the other hand, the translated simulator is not available, since we do not have information about
basic blocks of the original program. Debugging is also limited to the instruction level. The sourcelevel debugging is disabled because the debugging information is also unavailable.
Decompilation of the input binary executable is always possible, no matter if the source code or
debugging information is present. The input application is analyzed and the target architecture, file
format, and operating system are detected in preprocessing phase at first. In the same phase, we try to
detect the originally used compiler using the signature-based detection. This is useful in later phases
for generation of a more accurate code. The final step of the preprocessing phase is the conversion into
the COFF format as described in Section 3.
Afterwards, the front-end phase is automatically generated based on the detected target architecture
using the appropriate ISAC model. The machine code stored in the COFF file is transformed into its
semantics representation in the LLVM IR format using the instruction decoder. In the next-step, the
front-end performs several static analyses over the LLVM IR code, e.g. detection of functions,
removal of statically-linked code, control-flow analysis, recovery of data types [3]. The final phase of
front-end is the generation of the proper LLVM IR code that is passed to the middle-end.
Middle-end is responsible for code reduction and elimination of unneeded parts via several built-in
optimization passes. Finally, the results, still in the LLVM IR form, are processed in the back-end part.
It tries to detect and reconstruct the HLL constructions, such as loops, function calls, switch
statements, etc.
However, the output can be further enhanced using debugging information for the better readability
(e.g. variable and function names, position of code, source-code names, etc.), see the next scenario for
details.
4.2 EXECUTABLE WITH DEBUGGING INFORMATION
This situation is less common, but still plausible, e.g. distribution of beta-versions of applications to
testers. Debugging information can be exploited for generating translated simulator that can achieve
higher speeds (up to 120 MHz, in average 113MHz [12]). The simulation speed drop off in debugging
mode is about 1-12% based on the number of breakpoints and their positions within machine-code [8].
In theory, source-level debugging is allowed because debugging information is available (e.g.
mapping of code to the HLL statements, locations of variables); however, the source code is
unavailable and therefore, it is not possible to visualise the run-time information to the user. This
is one of the limitations of the state of the art. However, this issue is addressed in Section 5 and its
solution is proposed.
25
Decompilation can achieve the best results in this case. An example of source-code recovery using
debugging information can be seen in Fig. 4. In this example, the decompiler was able to reconstruct
even most of the local variable names, which are usually not available because they are removed by
compiler. The retargetable decompiler is capable to extract and reconstruct many program
constructions, e.g. file names (modules), function names, names and types of function arguments,
global and local variable names and types, positions of these constructions within modules (e.g. order
of originally used functions).
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
int main(int argc, char* argv[])
{
int iter;
double x, y, z;
printf("Iterations: ");
scanf("%d",&iter);
/* initialize random numbers */
srand(123456789);
/* cnt = number of points in the
1st quadrant of unit circle */
int cnt = 0;
int i = 0;
while (i++ < iter){
x = (double)rand() / RAND_MAX;
y = (double)rand() / RAND_MAX;
z = x*x + y*y;
if (z <= 1) cnt++;
}
double pi=(double)cnt / iter * 4;
printf("pi is %g\n", pi);
return 0;
}
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
typedef int int32_t;
typedef double float64_t;
int main(int argc, char **argv) {
int32_t cnt, i, iter;
float64_t y, x, y2, x2, x3, lemon;
cnt = i = iter = 0;
printf("Iterations: ");
scanf("%d", &iter);
lemon = (float64_t) 2147483647;
srand(123456789);
while (iter >= i) {
x3 = (float64_t) rand() / lemon;
y = (float64_t) rand() / lemon;
x = x3 * x3;
y2 = y * y;
x2 = x + y2;
cnt = x2 > 1.0 ? cnt : cnt + 1;
i = i + 1;
}
printf("pi is %g\n",
(float64_t)cnt / iter*4.0);
return 0;
Fig. 4: Computing Pi using Monte Carlo method (left – original C code, right – decompiled C code).
The debugging information in the DWARF format was used for decompilation.
4.3 SOURCE CODE AND DEBUGGING INFORMATION AVAILABLE
This is the ideal scenario of the executable-code analysis and it is also to most common one (e.g.
software development, precompiled open-source applications). All the previously mentioned features
are available as well as the source-level debugging. All the common debugging features are supported
(e.g. highlighting position within the source code, stack backtrace, inspecting variable values).
Although it is not obvious, the decompiler can be used too. It can be utilized for compiler testing via
26
Křoustek, Kolář
comparison of the original source code and the code decompiled from the compiler-generated
executables.
Finally, the decompilation results can be further enhanced via information gathered during simulation.
This can be done in all scenarios, i.e. with or without source-code or debugging information. The
description of this approach is given in the following section.
5 HYBRID ANALYSIS
In present, the static and dynamic analyses are isolated from each other; each analysis can be used
independently of the other one, e.g. we can use decompilation without running simulation and vice
versa. However, the outputs of each of them can be enhanced by outputs obtained in the other ones.
This concept is called hybrid analysis. Currently, we can find two fundamental techniques of hybrid
analysis:


Exploitation of the run-time information (generated during simulation) within decompilation.
This can be applied in all three scenarios described in Section 4.
Decompilation results (i.e. a HLL C code) can be used to support the source-code debugging
in scenarios where the source code or debugging information is unavailable (i.e. scenarios
described in Sections 4.1 and 4.2).
5.1 EXPLOITATION OF RUN-TIME INFORMATION IN DECOMPILATION
It is possible to gather a considerable amount of valuable information during the application’s
run-time, e.g. a list of called functions, reachable instructions, values read and written into variables.
On the other hand, it will be complicated or even impossible to get them during static analysis (e.g.
during decompilation).
The mentioned run-time information can be gathered by the simulator. Such mode of execution is
often referred to as a trace mode. The simulator stores all demanded information in an internal
database that aggregates the results (e.g. removal of duplicate values) and the database’s content is
passed to the decompiler at the end of simulation. One of the open problems is simulation of
applications that use dynamically linked code because the simulator must handle such situations (e.g.
syscalls, invocation of standard-library functions). This task is related to code emulation.
Afterwards, all of these values can be used during the decompilation. For example, the list of called
functions is usable in the function-detection algorithm (e.g. revelation of function’s called by
pointers), the list of positions can be employed for extracting targets of the indirect-branches (e.g.
branch to the address stored in some register), variable’s content during execution is important for the
value-range analysis.
5.2 SOURCE-CODE DEBUGGING USING DECOMPILATION
The second proposed technique can be done in two ways. (1) In the easier one, the debugging
information is available and the decompiler has to generate the target HLL code that corresponds to
given debugging information. The HLL code must satisfy the integrity, e.g. mapping of machine-code
27
instructions to HLL statements, mapping of variables to memory addresses, storage of local variables
on stack in a given order.
(2) The other case (i.e. both source-code and debugging information are unavailable) is a more
challenging task because both information have to be recreated during decompilation. Recreation of
the source code can be done in a classical way described in the previous sections. Recreation of the
debugging information related to the decompiled program can be tricky because the existing
debugging standards are complex and the size of debugging information is usually several times larger
than the application’s code. Furthermore, the debugging standard can be undocumented and
proprietary, such as Microsoft PDB.
The easiest solution is to generate a HLL code and re-compile it with debugging support enabled (e.g.
“-g” in GCC) using an appropriate compiler. Output of this process is a new executable with
debugging information that corresponds to the decompiled HLL code. However this may be an
unwanted behavior because it implies debugging of a different application. The other possible solution
is to recreate only a simplified version of debugging information by the decompiler itself (e.g. only
mapping of machine code to HLL statements).
The debugger must be prepared for this situation and allow a lightweight-debugging mode with only
a limited functionality. The DWARF standard suits this purpose better than PDB. Each type of
debugging information (e.g. position mapping, variable information) is stored in a separated file
section and its presence is optional. Furthermore, several existing libraries can be used for DWARF
generation (e.g. libDWARF).
6 CONCLUSION
This paper was aimed on the retargetable analysis of executables. Several methods of static and
dynamic analysis were presented, e.g. simulation, debugging, and decompilation. These methods are
implemented within the Lissom project as the automatically generated toolchain. These tools are
created based on the ISAC ADL models of the target architectures.
Using these tools, it is possible to inspect behavior of our own applications as well as the third-party
applications, which may be harmful (e.g. malware). The presented approach has been tested on the
MIPS architecture, while other architectures such as ARM or Intel x86 are supported too.
We close the paper by proposing an idea for the future research. We would like to interconnect the
static and dynamic analysis within the hybrid analysis. Two possible ways of its usage in the given
scenarios have been proposed; their implementation and evaluation is the primary target of the future
research.
ACKNOWLEDGMENTS
This work was supported by the project TAČR TA01010667 System for Support of Platform
Independent Malware Analysis in Executable Files, BUT grant FEKT/FIT-J-13-2000 Validation of
Executable Code for Industrial Automation Devices using Decompilation, BUT FIT grant FIT-S-11-2,
28
Křoustek, Kolář
by the project CEZ MSM0021630528 Security-Oriented Research in Information Technology, and by
the European Regional Development Fund in the IT4Innovations Centre of Excellence project
(CZ.1.05/1.1.00/02.0070).
7 REFERENCES
[1]
BARBE, P. The PILER system of computer program translation, Technical report, Probe
Consultants Inc., 1974.
[2]
CIFUENTES, C. Reverse compilation techniques, PhD thesis, School of Computing Science,
Queensland University of Technology, Brisbane, AU-QLD, 1994.
[3]
ĎURFINA, L., KŘOUSTEK, J., ZEMEK, P., KÁBELE, B. Detection and Recovery of
Functions and Their Arguments in a Retargetable Decompiler, In: 19th Working Conference
on Reverse Engineering (WCRE'12), Kingston, Ontario, CA, IEEE CS, 2012, pp. 51-60, ISBN
978-0-7695-4891-3.
[4]
ĎURFINA, L., KŘOUSTEK, J., ZEMEK, P., KOLÁŘ, D., HRUŠKA, T., MASAŘÍK, K.,
MEDUNA, A. Design of a Retargetable Decompiler for a Static Platform-Independent
Malware Analysis, In: International Journal of Security and Its Applications, Vol. 5, No. 4,
2011, Daejeon, KR, pp. 91-106, ISSN 1738-9976.
[5]
KÄSTNER D., WILHELM S. Generic control flow reconstruction from assembly code, In
Proceedings of the joint conference on Languages, compilers and tools for embedded systems:
Software and compilers for embedded systems (LCTES/SCOPES '02), ACM, New York, NY,
USA, pp. 46-55. 2002. URL http://www.absint.com
[6]
KINDER, J., VEITH, H. Jakstab: A static analysis platform for binaries, In Computer Aided
Verification, ser. Lecture Notes in Computer Science. Springer Berlin / Heidelberg, vol. 5123,
pp. 423–427, 2008.
[7]
KŘOUSTEK, J., MATULA, P., KONČICKÝ, J., KOLÁŘ, D. Accurate Retargetable
Decompilation Using Additional Debugging Information, In: Proceedings of the Sixth
International Conference on Emerging Security Information, Systems and Technologies
(SECURWARE'12), Rome, IT, IARIA, pp. 79-84, ISBN 978 1 61208-209-7, 2012.
[8]
KŘOUSTEK, J., PŘIKRYL, Z., KOLÁŘ, D., HRUŠKA, T. Retargetable Multi-level
Debugging in HW/SW Codesign, In: The 23rd International Conference on Microelectronics
(ICM 2011), Hammamet, TN, IEEE, pp. 6, ISBN 978-1-4577-2209-7, 2011.
[9]
LATTNER C. LLVM: An Infrastructure for Multi-Stage Optimization, Master’s Thesis,
Computer Science Dept., University of Illinois at Urbana-Champaign, Dec. 2002. URL
http://llvm.org/
[10]
MASAŘÍK, K. System for Hardware-Software Co-Design, FIT BUT, ISBN 978-80-214-38637, Brno, CZ, 2008, URL http://www.fit.vutbr.cz/research/groups/lissom/
[11]
MIPS Technologies Inc., MIPS32 Architecture for Programmers Volume II-A: The MIPS32
Instruction Set, 2010.
29
[12]
PŘIKRYL, Z. Advanced Methods of Microprocessor Simulation, PhD thesis, Brno University
of Technology, Faculty of Information Technology, Brno, CZ, p. 103, 2011.
[13]
PŘIKRYL, Z., KŘOUSTEK, J., HRUŠKA, T., KOLÁŘ, D. Fast Translated Simulation of
ASIPs, In: OpenAccess Series in Informatics (OASIcs), Vol. 16, No. 1, Wadern, DE, pp. 93100, ISSN 2190-6807, 2011.
[14]
RAMOS D. A., ENGLER, D. R. Practical, low-effort equivalence verification of real code, In
Proceedings of the 23rd international conference on Computer aided verification (CAV'11),
Springer-Verlag, Berlin, Heidelberg, pp. 669-685, 2011. URL http://www.coverity.com/
[15]
ROSENBERG, B. J. How Debuggers Work – Algorithms, Data Structures, and Architecture,
Wiley Computer Publishing, 1996.
[16]
VAN EMMERIK, M. Static Single Assignment for Decompilation, PhD thesis, School of
ITEE, University of Queensland, Brisbane, AU-QLD, 2007.
2(1), 2013, 30–38, DOI: 10.18267/j.aip.11
Online: aip.vse.cz
Section:
The adolescence of electronic health records:
Status and perspectives for large scale implementation
Stefan Sauermann1, Matthias Frohner1, Philipp Urbauer1, Mathias Forjan1,
Birgit Pohn1, Andreas Drauschke1, Alexander Mense1
1
University of Applied Sciences Technikum Wien
Hoechstaedtplatz 5, 1200 Vienna, Austria
[email protected]
Abstract: Health informatics started to evolve decades ago with the intention to
support healthcare using computers. Since then Electronic health records (EHRs)
and personal health records (PHRs) have become available but widespread
adoption was limited by lack of interoperability and security issues. This paper
discusses the feasibility of interoperable standards based EHRs and PHRs drawing
on experience from implementation projects. It outlines challenges and goals in
education and implementation for the next years.
Keywords: Electronic health record, Personal health record, Interoperability,
Standards, Feasibility
31
1 INTRODUCTION
1.1 IMPLEMENTATIONS IN THE FIELD
Two naive pictures exist for “biomedical informatics” in the wider public: One image shows highly
skilled individuals in white coats, doctors and engineers united, solving tricky problems elegantly with
help from modern devices and computing methods, saving lives and curing disease. The other image
shows desperate healthcare professionals bravely tackling the challenges of complex software. The
software in the second image tries to support care but actually consumes additional time and effort
while opening up new risks of data loss, confusion and unauthorized access to sensitive information.
One of the pioneers of the field, Edward Shortliffe, described the path of biomedical informatics in his
keynote lecture at the 2012 MIE conference in Pisa [23]. It started from medical schools in the 1960s,
gathered force and complexity as it spread to “informatics”, and is now well established both as an
industry as well as a distinctive field of research and development. Students enrolling biomedical
informatics study programs today have quite a clear image of the profession that they will join.
The information and communication technology (ICT) systems and applications that we see in
healthcare today have typically evolved in regional isolation, out of organizations like hospitals or
companies. Very seldom we find larger networks of systems, where data flows between healthcare
providers (HCPs) who do not meet personally. Today’s systems rely on human individuals with
oversight who can predict and verify what others will provide for them via the ICT system.
Information does not automatically find its way to the place where it is needed. Human gatekeepers
are still necessary who orchestrate the numerous sub-workflows in the specialized medical professions
as they together provide care to individual patients.
Because of their history, the systems available today are also not easy to tailor and adapt to
accommodate the requirements of specialized HCPs. In many places this has caused frustration and
a general bias against ICT in healthcare. The further sections will therefore explore the available
technology and the socio-political environment. This will enable to discuss near term goals that
contribute to the effective adoption of the available technologies in healthcare.
1.2 AVAILABLE TECHNOLOGY AND STANDARDS
Numerous successful examples of artificial intelligence have been demonstrated in practice. Two
decades ago the lack of interoperability standards has been identified as one main obstacle of
transferring ICT methods from one site to the next [22]. Recently strong evidence has emerged that
methods are available to overcome this problem.
Complementing the work of standards development organisations (SDOs, e.g. ISO, CEN, HL7)
“profiling organisations” like the Integrating the Healthcare Enterprise [16] initiative and the Continua
Health Alliance [6] have produced “profiles” of standards that cover selected use cases. While base
standards typically deal with detailed, isolated issues, the added value of profiles is that they cover
complete use cases. Using profiles implementers can therefore build complete solutions that draw
from multiple and complex base standards, enabling quick adoption of state of the art and proven
technologies. The records of the IHE testing events, called “Connectathons”, show that 505 companies
worldwide have implemented interoperable software for EHRs, radiology, laboratory, cardiology, eye
32
Sauermann et al.
care and others, implementing 116 integration profiles since the first Connectathon in 2001. Similarly
67 products have already reached Continua certification since the first product was certified in 2009. It
has been shown that even small research groups and SMEs can successfully implement complete
standards based telemonitoring systems within reasonable time and effort [25].
On the other hand large implementation projects are driven from administrations and large stakeholder
groups worldwide. The European projects www.epsos.eu and www.renewinghealth.eu are piloting
patient summary and medication workflows and telemonitoring on a large scale. National EHR
systems are built in Austria (www.elga.gv.at), Sweden (www.cehis.se/en), and many other countries.
The “EHR Incentive Program” [5] in the USA supports healthcare providers who implement
standards- based ICT infrastructures and clinical decision support, triggering a significant movement
towards implementation and certification of innovative and interoperable software products among
vendors. These national initiatives typically do not use the same set of IT architectures for connecting
local EHRs. However progress is visible. For example the epSOS infrastructure uses a common set of
interoperability standards and generates a common base that can be extended over time.
1.3 SOCIO-POLITICAL ENVIRONMENT
Students of today know rotary dials on telephones from the museum only. They watched the record
stratospheric dive in October 2012 live on a mobile device and commented to friends via twitter and
SMS when they rode on the bus [24]. In contrast, the doctors, politicians, company leaders, patients
and lecturers of today sent their first email when were already firmly settled in the early stages of
a professional career. The technology lifecycles have shortened dramatically.
On the other hand the influence of unhealthy lifestyles and demographic change on the health status of
populations is well documented [21]. Administrations are actively searching and evaluating strategies
to address sedentary lifestyles, unhealthy nutrition and other negative influences on public health on
a large scale [10]. The focus on lifestyle and prevention demands to extend the activities well beyond
the reach of healthcare professions. Many other groups will need to contribute, with the individuals
and patients themselves as the main advocates of their own health. Successful solutions need to
consider the wide variety of user needs and capabilities. State of the art ICT is deeply embedded into
these activities. A wide variety of health-related software products that use mobile technologies have
already reached the market and there are strong indicators for further growth in the near future [20].
The goal of this work was to assess the status of standards based semantic interoperability for EHRs
and PHRs on a large scale in order to better understand the extent of implementation we can expect in
the near future.
The underlying thesis of this work is that only within the last ten years technical specifications have
become available that enable large scale implementation of EHRs and PHRs. Technical specifications
in many variants have been available for much longer, for example from ISO [19], CEN [2], HL7 [11],
IHE [16], and Continua [6]. Nevertheless large scale implementation is not common so far. The
specifications alone therefore are not useful as sufficient evidence for large scale implementation.
Therefore additionally to the specifications publicly available testing tools and evidence of
implementation and testing activities were used as evidence.
33
2 MATERIALS AND METHODS:
EHR and PHR implementation projects were selected and studied. Selection criteria were:





The projects shall use specifications that are harmonised within an internationally recognised
organisation, for example ISO [19], CEN [2], HL7 [11], IHE [16], and Continua [6].
The projects shall target EHR or PHR implementation on a national or international scale,
potentially serving millions of patients. The necessary stakeholders shall be represented in the
project.
Projects shall involve implementation steps that are documented and publicly available
Documentation about testing activities of the project shall be available publicly
The authors shall be involved in the project, so that feasibility of implementation by SMEs
may be studied
The following projects were selected:




Austrian eHealth initiative: recommendations for an eHealth strategy for Austria (EHI, 0)
Implementation guides for medical reports in HL7 CDA format for the Austrian EHR
“ELGA” (ELGA CDA, http://www.elga.gv.at/index.php?id=28)
European patients smart open services (epSOS, http://www.epsos.eu)
Healthy Interoperability (HIO, [25])
During the projects information was collected and reviewed according to the following questions:







Which stakeholders (clinical users, software vendors, administration) were involved and
which specifications were used?
How much time did it take to generate the specifications?
Which level of detail was reached (basic architecture outline, detailed content and transaction
specifications)
In which way were the specifications then implemented (project was formed, legal
frameworks decided)?
Are formal testing tools for the specifications available?
Was the conformance of the implementations formally tested?
Is re-use of the specifications among the projects documented?
Only publicly available evidence documents were reviewed. These observations were then used to
discuss the feasibility of large scale implementation of semantic interoperability in comparison to the
situation described by Shortliffe in 1993 [22].
34
Sauermann et al.
3 RESULTS
3.1 SPECIFICATIONS, STAKEHOLDER INVOLVEMENT,
LEVEL OF DETAIL
In all projects interoperability specifications were defined for specific applications. In all projects
relevant stakeholders were engaged in the development and agreed on the resulting specifications. In
three of the four projects clinical users, software vendors as well as administration was involved. The
HIO project represents a SME implementing available specifications and therefore includes only one
software vendor. Tab. 1 summarises these findings and lists the reviewed sources.
Project
Type of stakeholders
Duration
Specifications
Level of implementation
EHI
>10 clinical users,
>10 software
vendors,
administration
20052007
Recommendations,
architectural framework 0,
national recommendation
on standards [3]
Only conceptive , taken
further within ELGA
ELGA
CDA
>10 clinical users,
>10 software
vendors,
administration
Since
2007
Technical specifications,
testing tools [8], legal
framework [2], [11]
Implementation under
way, operation in
Austrian hospitals
expected early 2015
epSOS
>10 clinical users,
>10 software
vendors,
administration
Since
2008
Technical Specifications
[11], legal requirements
[12]
Implemented, operative
HIO
1 Software vendor
20092012
Re-used available
specifications [25]
Software implemented
[25]
Tab. 1. Specifications resulting from projects, overview.
The projects that were studied have different scopes. EHI was a conceptive approach that only resulted
in very generic specifications. However all necessary stakeholders were represented and agreed on the
results. All other projects targeted and reached implementations. Especially ELGA CDA and epSOS
represent large scale projects that may be used to compare future large scale activities.
In three of the projects the specifications development lasted at least 2 years. HIO had a similar
duration than the other projects, but only a small part of that time was spent on the development of
specifications. HIO represents a typical SME activity in that it re-used existing specification
documents to develop an application that uses an available infrastructure provided by others as
described in [25].
35
3.2 TESTING TOOLS, TESTING ACTIVITY
In all projects where implementation occurred, testing specifications are available. Only within epSOS
interoperability was formally tested. However testing specifications for the specifications that were
used in HIO are also available. A list of certified products is publicly available. Tab. 2 summarises the
results and the related references.
Project
Testing tools
Testing activities
Test results publicly available
EHI
Not applicable
Not applicable
Not applicable
ELGA
CDA
Schematrons
available [9]
Only informal tests at
software vendors during
development
none
epSOS
Test specifications
[13]
Yearly formal epSOS
testing events took place
since 2010
Only overviews, e.g. [18],
IHE Connectathon Results
Database [17] addresses
specifications only partly
HIO
Continua
Certification
Specification [7]
Testing occurs regularly
at Plugfests and within
certification activities
[25], Continua certified
products database [8]
Tab. 2. Testing specifications and activities within projects, overview.
3.3 RE-USE OF SPECIFICATIONS
Re-use of existing specifications was found in all projects. Re-use between the studied projects only
occurred in the ELGA CDA project in that it re-used the basic recommendations that resulted from the
EHI. However the total project durations are similar in all studied projects. Successful re-use of
specifications was only possible after the source and target projects thoroughly analysed these issues.
Tab. 3 shows an overview of the most important specifications that were re-used in each project.
Project
EHI
Re-used existing specifications
HL7 CDA document architecture [15]
IHE IT Technical framework [16]
ELGA
CDA
EHI architectural guidance 0,
EHI recommendations for standards [3],
IHE IT Technical Framework [16],
epSOS
36
Sauermann et al.
HIO
Continua design Guidelines [6]
Tab. 3. Re-use of existing specifications in projects.
4 DISCUSSION AND CONCLUSIONS
Based on the observations from the projects that were studied it was found that semantic
interoperability for EHRs and PHRs on both national and international scale is possible in practice.
This is supported by the fact that software implementations were formally tested and are conformant
to the interoperability specifications of all projects that involved implementations.
From the results summarised in Tab. 1 it can be concluded that specifications are available both for
EHRs and PHRs. Tab. 2 additionally shows that methods are available and actively used to formally
test implementations against these specifications.
Tab. 3 shows a high level of overlap between the projects that were studied. This indicates that
a wider harmonisation of specifications has occurred: In 1993 Shortliffe expected that artificial
intelligence in medicine will become a reality only after “… the infrastructure for introducing
computational tools in medicine has been put in place by visionary leaders, who understand the
importance of networking, integration, shared access to patient data bases, and the use of standards for
data-exchange, communications and knowledge-sharing” [22]. The results of this work show that
substantial harmonisation effort has provided visible results since 1993. Common interoperability
standards therefore have moved from a faint hope to partial reality.
It was however found that substantial learning efforts were still necessary even if existing
specifications were re-used. This may be attributed to the fact that the necessary specifications cover
very wide topics and constitute a substantial amount of information, if reviewed in total. Additional
specification effort will be necessary to extend the defined functionality.
In this situation it seems reasonable to focus on a common learning effort that involves individuals,
administrations, healthcare providers, industry, academia and many other forces. As we go along, we
need to:





further explore and share interoperability technologies and standards,
actively engage users and solution providers of all origins,
learn from practice,
document and share experience,
sustain motivation and provide encouragement to all involved.
This work shows that the skills required for this exercise are available within biomedical informatics
as well as in many other disciplines. They have been exercised in first projects. The challenge of the
coming years will be to enrich the “low hanging fruit” applications and further empower
harmonisation work so that co-operation occurs during implementation.
37
Today we enjoy the luxury of all necessary components being ready, tested and available to all
interested communities within a reasonable time and effort. Never before has this been the case.
Within the next few years we will learn if and how fast we will be able to further develop common
visions and put them into practice. We will definitely see further obstacles that lie hidden in the dark.
We may however be surprised about the speed and success of progress.
5 REFERENCES
[1]
ARBEITSKREIS 1 DER ÖSTERREICHISCHEN EHEALTH INITIATIVE, Pfeiffer, P.;
Sauermann, S.; Leodolter, W.; Seeburger, H.; Hoellebauer, H.; Deutsch, E.; Pjeta, O. &
Holler, G. Pfeiffer, K. (Ed.). Empfehlung für eine österreichische e-Health Strategie - Eine
Informations- und Kommunikationsstrategie für ein modernes österreichisches
Gesundheitswesen. Bericht der Österreichischen e-Health Initiative, Stand Jänner 2007. 2007,
1-58. [cit. 2013-05-27] Online:
http://ehi.adv.at/fileadmin/user_upload/adv_author/pdfs/konferenz20070126/Strategie_Empfe
hlung_der_e-Health-Initiative_Oesterreich_20070126_v2_02.pdf
[2]
BUNDESGESETZ BGBL. Nr. 111/2012 (Austrian law): Elektronische GesundheitsakteGesetz - ELGA-G. [cit. 2013-05-27] Online:
http://www.elga.gv.at/fileadmin/user_upload/uploads/download_Papers/Gesetze_u.a._Rechtsg
rundlagen/BGBLA_2012_I_111.pdf
[3]
BUNDESMINISTERIUM FÜR GESUNDHEIT FRAUEN UND JUGEND (Austrian Federal
Ministry of Health). Standards im österreichischen Gesundheitswesen. 11.6.2007. Document
ID GFJ-72300/0025-I/A/15/20075/2007. [cit. 2013-05-27] Online:
rundlagen/BMGFJ_Standards_2007-06-11.pdf
[4]
CEN/TC 251. Published standards. [cit. 2013-05-27] Online:
http://www.cen.eu/CEN/Sectors/TechnicalCommitteesWorkshops/CENTechnicalCommittees/
Pages/Standards.aspx?param=6232&title=CEN/TC+251
[5]
CENTERS FOR MEDICARE AND MEDICAID SERVICES (CMS). The Official Web Site
for the Medicare and Medicaid Electronic Health Records (EHR) Incentive Programs. CMS,
Baltimore, MD, USA. [cit. 2013-05-27] Online: http://www.cms.gov/Regulations-andGuidance/Legislation/EHRIncentivePrograms/index.html?redirect=/ehrincentiveprograms/
[6]
CONTINUA HEALTH ALLIANCE. Continua Design Guidelines Version 2012. 2012. [cit.
2013-05-27] Online: http://www.continuaalliance.org/products/design-guidelines
[7]
CONTINUA HEALTH ALLIANCE. Certification Specification. [cit. 2013-05-27] Online:
https://cw.continuaalliance.org/wg/TCWG/documentRevision/download/10695
[8]
CONTINUA HEALTH ALLIANCE. Certified Products Showcase. [cit. 2013-05-27] Online:
http://www.continuaalliance.org/products/product-showcase
[9]
ELGA GmbH (Elektronische Gesundheitsakte Österreich). Harmonisierungsarbeit für
medizinische Dokumente. [cit. 2013-05-27] Online: http://www.elga.gv.at/index.php?id=28
[10]
EUROPEAN COMMISSION (EC). ICT Challenge 5: ICT for Health, Ageing Well, Inclusion
and Governance. ICT - Information and Communication Technologies in FP7, Work
Programme 2013, homepage, last update 2012-07-31. [cit. 2013-05-27] Online:
http://cordis.europa.eu/fp7/ict/programme/challenge5_en.html
[11]
EUROPEAN PATIENTS SMART OPEN SERVICES (European Project epSOS). Deliverable
D3.4.2, epSOS Common Components Specification. 16.7.2010. [cit. 2013-05-27] Online:
38
Sauermann et al.
http://www.epsos.eu/uploads/tx_epsosfileshare/D3.4.2_epSOS_Common_Components_Specif
ication_01.pdf
[12]
D2.1.1 - Legal and Regulatory Requirements at EU level. 24.2.2012. [cit. 2013-05-27] Online:
http://www.epsos.eu/uploads/tx_epsosfileshare/D2.1.1_legal_requ_final_01.pdf
[13]
D3.9.2 - Testing Methodology, Test Plan and Tools. 15.0.2010. [cit. 2013-05-27] Online:
http://www.epsos.eu/fileadmin/content/pdf/deliverables/D3.9.2_Testing_Methodology_Test_P
lan_and_Tools.pdf
[14]
GESUNDHEITSTELEMATIKVERORDNUNG - GTELV 2012. [cit. 2013-05-27] Online:
rundlagen/BGBLA_2012_II_483.pdf
[15]
HEALTH LEVEL SEVEN (HL7) INTERNATIONAL. Homepage. [cit. 2013-05-27] Online:
http://www.hl7.org/
[16]
INTEGRATING THE HEALTHCARE ENTERPRISE (IHE). IHE Technical Frameworks.
[cit. 2013-05-27] Online: http://www.ihe.net/Technical_Framework/index.cfm
[17]
INTEGRATING THE HEALTHCARE ENTERPRISE (IHE). Connectathon results browsing.
[cit. 2013-05-27] Online: http://connectathon-results.ihe.net/
[18]
INTEGRATING THE HEALTHCARE ENTERPRISE (IHE). IHE-Europe Connectathon
2013 enables robust, in-depth testing for HIT interoperability. Press release 6.5.2013. [cit.
2013-05-27] Online: http://www.ihe-europe.net/sites/default/files/IHEEurope%20Connectathon%202013%20Press%20Release.pdf
[19]
ISO/TC 215 HEALTH INFORMATICS. Homepage. [cit. 2013-05-27] Online:
http://www.iso.org/iso/iso_technical_committee?commid=54960
[20]
LIEBERT, M. A. Report sees fastest growth at home, as telemed swells to $23B by 2015.
Telemedicine and e-Health News Alert, 2011. [cit. 2013-05-27] Online:
http://www.telemedicinealerts.com/Archives/2011/Feb_11/Feb_18_11.htm
[21]
PINIEWSKI, B.; CODAGNONE, C.; OSIMO, D. Nudging lifestyles for better health
outcomes: crowd sourced data and persuasive technologies for behavioural change European
Commission. Joint Research Centre, Institute for Prospective Technological Studies, 2011, 178. [cit. 2013-05-27] Online: http://ftp.jrc.es/EURdoc/JRC64206.pdf
[22]
SHORTLIFFE E.H. The adolescence of AI in Medicine: Will the field come of age in the 90s?
Artificial Intell.Med. 5, 1993, 93-105.
[23]
SHORTLIFFE, E.H. The Future of Biomedical Informatics: A Perspective from Academia. In:
Quality of Life through Quality of Information. J. Mantas et al. (Eds.), IOS Press, 2012,
European Federation for Medical Informatics and IOS Press. Proceedings of the 24th
European Medical Informatics Conference - MIE2012 - in Pisa, Italy, August 26th -29th, 2012
doi:10.3233/978-1-61499-101-4-19.
[24]
SMITH C. Red Bull Stratos YouTube Live Stream Attracts Record Number Of Viewers. The
Huffingtom Post, New York City, United States. 14th October 2012. [cit. 2013-05-27]
Online: http://www.huffingtonpost.com/2012/10/14/red-bull-stratos-youtube_n_1965375.html
[25]
URBAUER, P.; FROHNER, M.; FORJAN, M.; POHN, B.; SAUERMANN, S.; MENSE, A. A
Closer Look on Standards Based Personal Health Device Communication: A Résumé over
Four Years Implementing Telemonitoring Solutions. European Journal for Biomedical
Informatics, Vol. 8(2012), Issue 3, pp. 65-70, ISSN 1801-5603.
2(1), 2013, 39–56, DOI: 10.18267/j.aip.12
Online: aip.vse.cz
Sekce / Section:
Vplyv sofistikovaného hybridného Honeypotu na efektivitu
architektúry systému detekcie prieniku v distribuovaných
počítačových systémoch
Peter Fanfara1, Martin Chovanec2
1
Katedra počítačov a informatiky, Fakulta elektrotechniky a informatiky
Technická univerzita v Košiciach, Letná 9, 04001 Košice, Slovenská republika
2 Ústav Výpočtovej Techniky, Technická univerzita v Košiciach
Boženy Němcovej 3, 04001 Košice, Slovenská republika
{peter.fanfara, martin.chovanec}@tuke.sk
Abstrakt: Pri súčasnom vývoji technológií, rapídnom raste počítačových sietí
a distribuovaných systémov, je reálne riziko útoku čoraz pravdepodobnejšie. Pre
zvýšenie samotnej bezpečnosti systémov už bolo vytvorených a implementovaných
množstvo riešení, ktoré mali slúžiť na detekciu a/alebo prevenciu pred samotnými
útokmi. Najpoužívanejšie riešenie predstavuje použitie systému na detekciu
prieniku (IDS) v kooperácii s firewallom. Avšak ani IDS a ani firewall nedokážu
reagovať v reálnom čase, pokiaľ sa jedná o špecifický typ útoku. Táto práca sa
zaoberá detekčným mechanizmom na báze technológie Honeypot a jeho využitím
v navrhovanej architektúre pre zvýšenie bezpečnosti v počítačových systémoch.
Podstatou práce je poukázať na to, ako dokáže sofistikovaný hybridný Honeypot
vplývať na dizajn architektúry IDS a tým zvýšiť jej efektivitu.
Klíčová slova: bezpečnosť počítačových systémov, honeypot, systém detekcie
prienikov, škodlivý kód
Title: Influence of Sophisticated Hybrid Honeypot on Efficiency of Intrusion
Detection System Architecture in Distributed Computer Systems
Abstract: In the current development of technologies, rapid growth of computer
networks and distributed systems still exist a very probable risk of attack. There
have been developed and implemented a number of solutions to help in detecting
and/or preventing attacks and to improve the actual system security. The most
common solution is to use Intrusion Detection System (IDS) in cooperation with
the firewall. Neither the IDS nor firewall can respond in real time to a specific type
of attack. This paper deals with the detection mechanism based on Honeypot
technology and its use in the proposed architecture to improve security of computer
systems. The essence of the work is to show how can sophisticated hybrid
Honeypot influence the design of IDS architecture and thus increase its efficiency.
Keywords: Intrusion Detection System (IDS), Honeypot, Malicious code, Security
40
Fanfara, Chovanec
1 ÚVOD
Vzhľadom k rýchlemu šíreniu internetu a webových technológií môžu ľudia ľahko a jednoducho
vyhľadávať informácie a zároveň rýchlo posielať správy. Avšak, ak nebudeme súčasne klásť
dostatočne veľký dôraz, adekvátny rýchlemu rozvoju internetu, na základné zabezpečenie systémov,
hackeri môžu poľahky ovládnuť zabezpečenie systému použitím škodlivého kódu, využitím
existujúcich zraniteľností systému alebo programových slabín. Potom invázia, ničenie a krádeže, ako
aj falšovanie informácií spôsobia veľké škody väčšine podnikov a na majetku osôb. Dôsledkom
potenciálnej hrozby vzniká v dnešnej dobe čoraz väčší záujem o zvýšenie bezpečnosti informácií, ako
aj detekciu prienikov.
Začiatky detekcie prienikov priniesli so sebou aj komplikácie. Medzi teoretickou a praktickou rovinou
detekcie prienikov stále existuje priepasť. Táto situácia vytvorila všetky druhy skúšok pre skúmané
a rozvíjajúce sa produkty v tejto oblasti. Sú tu pokusy definovať priebežne termíny a vyvíjať
adekvátne riešenia, ktoré kooperujú s ostatnými časťami bezpečnostného systému alebo s riadiacou
infraštruktúrou. Ďalší významný pokus je požiadavka, aby preferované riešenie alebo prístup riešili
všetky problémy bez ohľadu na platnosť tvrdenia.
Zaužívaná obrana siete/systému je postavená na použití firewallu a systému na detekciu prienikov
(Intrusion Detection System – IDS). Tieto dva systémy prinášajú zo sebou dva druhy otázok. Akonáhle
sú útočníci informovaní o tom, že firewall má povolenú bezpečnostnú výnimku pre vonkajšiu službu,
dokážu využitím tejto služby získať prístup k interným serverom a prostredníctvom brány firewall
uskutočniť ďalší útok. Za druhé, systém na detekciu prienikov nedokáže poskytnúť dodatočné
informácie pre zistenie nepriateľských útokov, ako aj nedokáže priamo znížiť straty spôsobené
takýmito útokmi [1].
Ak by sme boli, hneď pri prvom útoku, schopný okamžite zaznamenať neznámu zraniteľnosť a možný
útok na počítač v systéme, analyzovať neznámy útok a postúpiť výsledky o podobných varovaniach
bezpečnostným špecialistom, bola by niekoľkonásobne vyššia šanca vydať výstrahy pre zabezpečenie
systémov, nájsť analyzované vzory útokov, možných rizík, metód a nástrojov, a tak v predstihu
zabrániť potencionálnym útokom i ďalším poškodeniam. Takýmto postupom by sme dokázali
v predstihu účinne znížiť a zmierniť riziko bezpečnosti informácií.
Tradičný prístup k zabezpečeniu je značne mierne zameraný na obranu, ale záujem je čím ďalej, tým
viac venovaný agresívnejším formám obrany pred potencionálnymi útočníkmi a narušiteľmi. Takouto
formou je aj ochrana pred vniknutím založená na návnade prostredníctvom technológie lákadla
(Honeypot).
2 SYSTÉMY NA DETEKCIU PRIENIKOV (IDS)
Systém na detekciu prienikov možno definovať ako nástroj alebo softvérovú aplikáciu, ktorá
monitoruje činnosti počítačového systému a/alebo siete kvôli potencionálnemu výskytu nebezpečných
aktivít alebo porušenia bezpečnostnej politiky. Produkuje správy pre riadiacu stanicu. Primárne je
zameraný na identifikáciu a zaznamenávanie informácií o prípadných udalostiach, ako aj hlásenie
takýchto pokusov.
41
2.1 KLASIFIKÁCIA SYSTÉMOV NA DETEKCIU PRIENIKOV
Vzhľadom k rozličným aplikačným prostrediam je možné IDS klasifikovať do dvoch hlavných typov
[2]:


Hostiteľský (host-based) – pozostáva z agenta umiestneného na hostiteľskom počítači, ktorý pre
kontinuálne monitorovanie používa informácie získané zo samotného auditného systému
hostiteľského počítača alebo záznamy sieťových aktivít. V takomto IDS senzor zvyčajne obsahuje
aj softvérového agenta. Ak nastanú neobvyklé okolnosti systém automaticky vygeneruje a odošle
upozornenie. Nevýhodou je zvyčajne veľké množstvo dát určené na monitorovanie.
Sieťový (network-based) – predstavuje nezávislú platformu pre identifikovanie prienikov
prostredníctvom priameho zachytenia prenášaných paketov v sieti a monitorovanie viacerých
počítačov na identifikovanie, či sa jedná o útok alebo inváziu na základe sledovania hlavičky
a obsahu jednotlivých paketov. Sieťové systémy detekcie prienikov (NIDSs) získavajú prístup
k sieťovej prevádzke pripojením sa k sieťovému rozbočovaču (network hub), sieťovému prepínaču
(network switch) nakonfigurovanom na zrkadlenie portov. V NIDS sú senzory na detekciu
umiestňované na kritické miesta v sieti, vo väčšine prípadov sú to hranice siete alebo tzv.
demilitarizované zóny. Tieto senzory zachytávajú všetku sieťovú prevádzku a analyzujú obsah
jednotlivých paketov kvôli výskytu nebezpečnej prevádzky. Nevýhodou je konzumácia väčšiny
systémových prostriedkov a sieťovej prevádzky. Príliš veľká sieťová prevádzka zapríčiní
nemožnosť alebo nesprávnosť spracovania paketov systémom na detekciu prienikov.
Vzhľadom na metódy detekcie je možné IDS rozdeliť na tri základné typy [3]:



Detekcia anomálií (anomaly detection) – odkazuje na zistenie štruktúry v danom súbore dát, ktoré
nie sú v súlade s bežným správaním. Takto zistené štruktúry sa nazývajú anomálie. Detekcia
anomálií stanovuje základný výkon pre normálnu prevádzku v sieti. Poplach zaznie len v prípade,
ak je aktuálna prevádzka v sieti mimo základných parametrov – vyskytla sa anomália.
Detekcia zneužitia (misuse detection) – zhromažďuje charakteristiky a vzory predchádzajúceho
útoku hackera a pričom ich ukladá do databázy medzi základné znalosti útoku. Následne dokáže
identifikovať útok, ktorý má rovnaké vzory a charakteristiky, ako už predtým zaznamenaný útok.
V prípade, ak hacker použite na útok novú metódu, ktorá ešte nebola pred tým zaznamenaná, IDS
nedokáže spustiť poplach a vznikne hlásenie typu falošné negatívum (false negative).
Hybridný mód detekcie (hybrid mode detection) – predstavuje detegovanie útoku za pomoci
oboch predchádzajúcich typov detekcie, čo má za následok zníženie generovania falošného
poplachu, aj keď sa nič nedeje (false positives), ako aj negenerovanie poplachu pri nezachytení
útoku (false negatives).
2.2 ŠTRUKTÚRA A ARCHITEKTÚRA IDS
Systém na detekciu prienikov pozostáva z viacerých prvkov, znázornených na Obr. 1, kde hlavným
prvkom je senzor (mechanizmus analýzy), ktorý je zodpovedný za detekciu narušenia. Tento snímač
obsahuje mechanizmus, ktorý generuje rozhodnutia týkajúce sa narušenia. Senzor príjme dáta z troch
hlavných zdrojov informácií: vlastná IDS databáza poznatkov, logovacie záznamy systému
a kontrolné záznamy. Logovacie záznamy systému môžu zahŕňať, napr. konfiguráciu súborového
42
Fanfara, Chovanec
systému a používateľské oprávnenia. Tieto informácie tvoria základ pre ďalšie rozhodovanie pri
detekcii narušenia.
chránený počítačový systém
akcie
kontrolné záznamy a sieťový monitoring
IDS databáza
poznatkov
senzor
(rozhodovací
mechanizmus)
databáza IDS
konfigurácie
modul reakcie
na útok
IDS
Obr. 1. Systém na detekciu prienikov.
Senzor, spolu s ostatnými prvkami znázornenými na Obr. 2, je integrovaný spolu s prvkom
zodpovedným za zber dát – generátor udalostí. Spôsob zbierania dát je určený politikou generátora
udalostí, ktorý definuje spôsob filtrovania informácií notifikovania o udalostiach. Generátor udalostí
(operačný systém, siete, aplikácie) produkuje v súlade s bezpečnostnou politikou súbor udalostí, ktorý
môže byť logovacím záznamom systémových udalostí, prípadne sieťových paketov. Tieto udalosti
môžu byť spolu s informačnou politikou uložené buď v chránenom systéme alebo mimo neho.
V prípade sieťových paketov sa prúdy udalostí neukladajú, nakoľko sú prenášané priamo do
analyzátora.
43
Chránený systém
generátor
udalostí
súbor
udalostí
politika zbierania
informácií
Zbieranie informácií
analyzátor
(senzor)
informačný
systém
detekčn
á
Detekcia
reakčný
modul
reakčná
politika
Reakcia
Obr. 2. Prvky systému detekcie prieniku.
Úlohou senzora je filtrovanie informácií a odignorovanie všetkých irelevantných údajov získaných zo
súboru udalostí súvisiacich s chráneným systémom a tým odhaliť podozrivé aktivity. Na tento účel
využíva databázu detekčnej politiky, ktorá sa skladá z nasledujúcich prvkov: útok podľa vzoru,
normálne správanie, profily a potrebné parametre. Okrem toho databáza obsahuje aj parametre IDS
konfigurácie a spôsob komunikácie s reakčným modulom. Vlastnú databázu má aj senzor, ktorá
obsahuje dynamickú históriu komplexu potenciálnych prienikov.
2.3 NÁSTROJE DETEKCIE PRIENIKOV
Systémov na detekciu prienikov existuje veľké množstvo a môžu byť špecifické pre systém použitím
vlastných nástrojov. Najčastejšie používaný je multiplatformový nástroj Snort, ktorý má navyše
výborné predpoklady pre použitie na zvýšenie bezpečnosti distribuovaných systémov v kombinácii
s Honeypotom.
Snort
Nástroj Snort predstavuje open-source systém na detekciu prieniku, ktorý dokáže nielen detegovať
a upozorniť na útok, napr. proti Honeypotu, ale dokáže aj zachytiť pakety a zaťaženie siete danými
paketmi zahrnutými do útoku. Tieto informácie sa môžu ukázať ako kritické pri analýze aktivít
útočníkov. Pre projektovanie používa modulárnu architektúru a pravidlami riadený jazyk. Kombinuje
abnormálne správanie, detekciu podpisu a rôzne metódy detekcie protokolu [4].
Aby bolo možné čo najúspešnejšie sledovať činnosti hackerov v distribuovaných počítačových
systémoch, udomácnila sa metodika klamania a podvádzania, prostredníctvom poskytnutia
a emulovania niektorých služieb systému, ktorý sa na prvý pohľad zdá byť legitímny. Z dôvodu
preniknutia a objasnenia jednotlivých taktík útočníkov je potom možné všetky aktivity hackerov
zaznamenať a monitorovať. Táto idea je prijatá použitím pokročilého bezpečnostného nástroja
zvaného Honeypot.
44
Fanfara, Chovanec
3 HONEYPOT
Honeypot je zložité definovať, pretože sa jedná o novú a stále sa vyvíjajúcu technológiu, ktorú je
možné zahrnúť do rôznych aspektov bezpečnosti, ako je prevencia, odhaľovanie a zhromažďovanie
informácií. Jedinečnosť technológie spočíva v jej všeobecnosti a nie v konkrétnosti – nerieši
špecifický bezpečnostný problém. Práve naopak, Honeypot je vysoko-flexibilný nástroj s aplikáciami
v rôznych oblastiach. Všetko záleží na tom, čo chceme dosiahnuť. Niektorými lákadlami možno
zabrániť útokom, iné možno použiť na detekciu útokov, zatiaľ čo ostatné lákadlá môžu byť použité pre
zhromažďovanie informácií a výskum.
Lákadlá, ako sa niekedy Honeypoty nazývajú, sú pozorne monitorované sieťové návnady, existujúce
v rôznych tvaroch a veľkostiach, slúžiace rôznym účelom. Je možné ich umiestniť v počítačovej sieti,
s firewallom, pred firewall aj za firewall. Toto sú najfrekventovanejšie miesta, z ktorých získavajú
útočníci prístup do systému a aj odkiaľ je o nich možné najlepšie získať maximum informácií.
Cieľom je získať informácie ohrozením dát systému takým spôsobom, že v budúcnosti bude
infiltrovanie akýchkoľvek dát systému nerealizovateľné.
Dáta získané z Honeypotov je možné využiť pri zlepšení súčasného zabezpečenia a obrany, alebo
rekonfiguráciu systému s prípravou na budúce hrozby.
3.1 ROZDELENIE HONEYPOTOV
Honeypoty môžu byť klasifikované podľa rôznych spôsobov. Najčastejšie je zaužívané ich
rozdeľovanie podľa účelu a úrovne interakcie.
3.1.1
ÚČEL HONEYPOTU
Toto základné delenie rozdeľuje lákadlá na základe oblasti nasadenia a dôvodu použitia.
Výskumný Honeypot
Hlavným cieľom, nakoľko sú používané výhradne v oblastiach výskumu, je získať čo najviac
informácií o útočníkoch spôsobom, že sa im plne umožní infiltrovať a preniknúť do bezpečnostného
systému. Používa sa na získanie informácií a rozpoznávanie nových metód a druhov nástrojov
používaných pri útoku na iné systémy, ako aj analyzovanie stôp hackerov, ako je totožnosť útočníkov
a ich spôsob práce (modus operandi).
Výskumný Honeypot je navrhnutý na získanie informácií o ľubovoľnej komunite útočníkov, pričom
nepridáva žiadnu priamu hodnotu, ktorá by mohla zvýšiť riziko útoku. Používa sa na zhromažďovanie
informácií o útokoch, ktorým môžu organizácie čeliť a tým im umožní, lepšie sa pred danými
hrozbami chrániť. Primárnou funkciou je skúmať spôsob, akým útočníci postupujú a vedú útok.
Pomáha pochopiť ich motívy, správanie a organizáciu. Výskumné lákadlá sú komplexné, čo sa týka
nasadenia, udržiavania a zachytenia rozsiahleho množstva dát. Na druhej strane ale môžu byť z
časového hľadiska veľmi rozsiahle [5].
Aj napriek informáciám získaným z jedného výskumného Honeypotu, ktoré sa môžu použiť na
zlepšenie prevencie proti útoku, zlepšenie detekcie a odpovedi na útok, výskumný Honeypot prispieva
45
celkovo k priamej bezpečnosti len veľmi málo. Výskumné Honeypoty pridávajú obrovskú hodnotu pre
výskum, nakoľko poskytujú platformu pre skúmanie kybernetických hrozieb. Útočníkov je možné
sledovať priamo pri čine, zaznamenávať ich útok a narušenie systému krok po kroku. Takéto
zhromažďovanie informácií je jednou z jedinečných a ohromujúcich vlastností Honeypotu. Taktiež je
to vysoko-prospešný bezpečnostný nástroj v oblasti rozvoja analyzovania a forenzných schopností [6].
Produkčný Honeypot
Jedná sa o typ lákadla, ktoré je použité v prostredí organizácie na jej ochranu a pomoc pri znížení
miery rizika. Poskytuje okamžité zabezpečenie lokality výrobných kapacít a nástrojov. Vzhľadom
k tomu, že nevyžaduje takú funkcionalitu ako výskumný Honeypot, je zvyčajne jeho vývoj
a nasadenie značne jednoduchšie. Hoci dokáže identifikovať rôzne spôsoby útokov, poskytuje menej
informácií o útočníkovi ako výskumné Honeypoty. Jeho použitím je možné určiť z ktorého systému
útočníci pochádzajú, ktorú konkrétnu činnosť vykonali, ale nemožno určiť ich identitu alebo aké
nástroje používajú [5].
Používa sa na ochranu siete pred nebezpečnými aktivitami útočníkov, detekciu a izolovanie útokov
vonkajších narušiteľov a spomalenie útoku na skutočné ciele systému, ako aj na zníženie rizík
informačnej bezpečnosti. Umiestňuje sa v sieťach z dôvodu zvýšenia celkovej bezpečnosti
spoločnosti, kde pomáhajú pri odhaľovaní útokov. Majú tendenciu zrkadliť časti siete spoločnosti
alebo špecifické služby a ich simuláciou prilákať pozornosť útočníkov, aby s nimi zahájili interakciu
s cieľom odhaliť aktuálne zraniteľné. Odhaľovanie týchto bezpečnostných nedostatkov a upozornením
administrátora o útoku môžu poskytnúť včasné varovanie pred útokom a výrazne redukovať riziko
prieniku do systému [7].
Je potrebné zdôrazniť, že produkčný Honeypot má ako preventívny mechanizmus minimálnu hodnotu.
Najvhodnejšími postupmi implementovania Honeypotu je využitie firewallu, systémov na detekciu
prieniku (IDS), mechanizmus na uzamknutie a opravu systému [8].
3.1.2
ÚROVEŇ INTERAKCIE
Úroveň interakcie môže byť definovaná ako maximálny rozsah dostupných možností útoku,
umožnený samotným Honeypotom, ktorý má útočník k dispozícii. Hodnota technológie závisí na
úrovni interakcie s útočníkmi. Všetky Honeypoty fungujú na rovnakom koncepte – nikto by nemal
prísť do styku s lákadlom a preto akékoľvek transakcie alebo interakcie sú, na základe definície,
neoprávnené. Okrem základného rozdelenia na výskumný a produktívny Honeypot je možné lákadlá
kategorizovať aj podľa stupňa interakcie medzi narušiteľom a systémom. Je to akási pomôcka pri
výbere správneho typu lákadla pre nasadenie do systému.
Nízka interakcia
Lákadlo na tejto úrovni interakcie neobsahuje žiadny operačný systém, s ktorým by útočník mohol
komunikovať. Všetky nástroje sú nainštalované výhradne k emulovaniu operačného systému a jeho
najzákladnejších služieb, ktoré nemôžu byť využité k získaniu úplného prístupu k/do Honeypotu tak,
aby spolupracovali s útočníkmi a škodlivým kódom [9][10].
46
Fanfara, Chovanec
Interakcia systému s útočníkmi je limitovaná a len počas krátkej doby, takže útočníci majú
niekoľkonásobne sťažené preniknutie do systému. Útočníci môžu daný Honeypot len skenovať
a pripojiť sa na niekoľko portov. Tento typ lákadla sa používa na zabezpečenie systému pred
potenciálnymi útočníkmi, čo na druhej strane spôsobuje získanie obmedzeného počtu informácií
o narušiteľoch. Lákadlá s nízkou interakciou môžu byť porovnávané k pasívnym systémom na
detekciu prieniku, nakoľko žiadnym spôsobom neovplyvňujú prevádzku v systéme a takisto nedokážu
ani komunikovať s útočníkom. Hoci takéto riešenie minimalizuje mieru ohrozenia Honeypotu, je na
druhej strane, z dôvodu schopnosti nízkej interakcie útočníka s lákadlom, získavanie informácií
o útočníkoch veľmi obmedzené. Avšak stále je možné ho použiť pri analyzovaní spamerov a ako
aktívne protiopatrenie proti červom. Honeypoty s nízkou interakciou sú charakteristické možnosťou
ľahkého nasadenia a udržiavania [8].
Stredná interakcia
V porovnaní s predchádzajúcim typom interakcie sú stredné Honeypoty trochu sofistikovanejšie. Ani
tento typ nemá nainštalovaný operačný systém, ale simulované služby na tomto type lákadla sú
technicky viac komplexnejšie. Aj keď sa pravdepobnosť, že útočník nájde slabinu v zabezpečení
systému zvyšuje, je stále málo pravdepodobné, že systém bude ohrozený. Lákadlá so strednou
interakciou poskytujú útočníkovi ilúziu operačného systému, pretože obsahujú viacero emulovaných
služieb, s ktorými môže vzájomne komunikovať. Dôsledkom toho môžu byť zaznamenané
a analyzované aj zložitejšie typy útokov [8].
Vysoká interakcia
Jedná sa o najmodernejšie typy lákadiel, ktoré predstavujú riešenie s najkomplexnejším a časovonáročným dizajnom s najvyššou mierou rizika, pretože v sebe zahŕňajú aj funkčný operačný systém
[10]. Cieľom Honeypotov s vysokou interakciou je poskytnúť útočníkovi možnosť komunikovať so
skutočným operačným systémom, v ktorom nie je nič simulované, emulované alebo obmedzené.
Umožňuje zber najväčšieho množstva informácií, nakoľko dokáže zaznamenať a analyzovať všetky
vykonané aktivity [1].
Vzhľadom k tomu, že útočník má k dispozícií viac zdrojov, malo by byť lákadlo s vysokou interakciou
pod neustálym monitorovaním, aj z dôvodu zníženia nebezpečenstva alebo vzniknutia bezpečnostnej
diery. Hlavný dôraz je kladený na získanie cenných informácií o narušiteľoch, sprístupnením celého
systému alebo dokonca umožnením manipulácie s ním. Pomocou tohto rýdzo výskumneorientovaného lákadla je možné objaviť nové techniky používané narušiteľmi [10].
3.2 ARCHITEKTÚRA HYBRIDNÉHO HONEYPOTU
Hybridné lákadlo predstavuje kombináciu dvoch lákadiel s rôznou úrovňou interakcie. Kombinácia
dvoch rôznych Honeypotov predstavuje bezpečné riešenie, nakoľko je možné využiť výhody obidvoch
lákadiel, znázornené v Tabulka 1, tak, že sa navzájom dopĺňajú a tým obmedzujú svoje nevýhody.
Ideálnym riešením je kombinácia Honeypotu s nízkou a vysokou interakciou. Honeypot s nízkou
interakciou
vystupuje
ako
ľahké
proxy,
čím
odbremeňuje
Honeypot
s vysokou interakciou – nezapája ho do všetkých útočníkových aktivít ako je automatizovaný proces
skenovania samotného systému, čím mu umožňuje zamerať sa na spracovanie podstatných
47
útočníkových aktivít spojených s procesom prieniku do systému a prenosov smerovaných
k špecifickému IP adresného priestoru, na ktorom je hybridný Honeypot nainštalovaný [11]. Akonáhle
Honeypot s nízkou interakciou vyhodnotí/deteguje, že sa nejedná o žiadny automatizovaný proces,
aktivuje sa Honeypot s vysokou interakciou pre záznam informácií, na základe ktorých je možné
zlepšiť samotnú bezpečnosť systému.
Honeypot s vysokou
interakciou
Honeypot s nízkou
interakciou
Hybridný
Honeypot
- pomalý
+ rýchly
+ rýchly
+ možnosť detegovania
neznámych útokov
- absencia možnosti
detegovania neznámych útokov
+ možnosť detegovania
neznámych útokov
+ 0 falošne detegovaných
útokov
+ 0 falošne detegovaných
útokov
- neschopný odolať časovým
bombám, plytvanie výkonu
pri automatizovaných
procesoch útočníkov
+ odolá časovým bombám
a postačujúci pre interakciu
s automatizovanými procesmi
útočníkov
+ odolá časovým bombám
a postačujúci pre interakciu
s automatizovanými procesmi
útočníkov
- drahý
+ lacný
+ relatívne drahý
- zložitý na nastavenie
a ovládanie
+ jednoduchý na nastavenie aj
ovládanie
- zložitý na nastavenie
a ovládanie
Tab. 1. Podstata hybridných Honeypotov.
Pri každom návrhu lákadla sa jeho implementovanie do systému nezaobíde bez použitia jedného alebo
viacerých implementačných nástrojov, ktoré majú značný význam v oblasti zvyšovania zabezpečenia
systémov:


Dionaea je modulárna architektúra využívajúca Honeypot s nízkou interakciou, ktorá umožňuje
simulovať hlavné služby i zraniteľnosť serverov a takýmto spôsobom upútať útočníkovu
pozornosť alebo zachytiť škodlivý kód [12].
Sebek je najpokročilejší komplexný nástroj pre zhromažďovanie dát, ktorého cieľom je zachytiť
z Honeypotu čo najviac informácií o činnosti útočníka, zastavením konkrétneho systémové
volania (syscalls) na úrovni jadra (kernel level) [12].
3.3 VÝHODY A NEVÝHODY POUŽÍVANIA HONEYPOTOV
Všetky bezpečnostné technológie majú určité riziko. Pokiaľ znalosti a skúsenosti predstavujú výhodu
pre útočníkov, platí to takisto aj pre bezpečnostných odborníkov. Je nutné ovládať jednotlivé výhody
48
Fanfara, Chovanec
aj nevýhody lákadiel, nakoľko uvedomenením si vlastného rizika Honeypotu je možné použiť tieto
znalosti na zmiernenie rizík a obídenie, resp. maximálne minimalizovanie možných nevýhod [8].
Použitie Honeypotov má niekoľko významných výhod v porovnaní so súčasnými najčastejšie
používanými bezpečnostnými mechanizmami [11]:





Malé dátové sady (small data sets) – Honeypoty dokážu sledovať len prevádzku, ktorá
prichádza priamo do nich. Dátové sady lákadla môžu byť malé, ale na druhej strane môžu
obsahovať informácie vysokej hodnoty.
Jednoduchosť (simplicity) – lákadlá sú veľmi jednoduché a flexibilné. Pre plnenie správnej
funkčnosti v počítačovej bezpečnosti nepotrebujú návrhy komplikovaných algoritmov,
aktualizovanie a udržiavanie stavových tabuliek alebo signatúr.
Objavenie nových nástrojov a taktík (discovery of new tools and tactics) – Honeypoty
zachytia všetko, čo sa dostane s nimi do interakcie, ako aj pred tým ešte nepoužité nástroje
a taktiky útočníkov.
Šifrovanie alebo IPv6 (encryption or IPv6) – implementácia lákadiel funguje aj v šifrovanom
alebo IPv6 prostredí.
Minimálne zdroje (minimal resources) – vzhľadom k tomu, že zachytávajú len škodlivé
aktivity, potrebujú k správnej funkčnosti minimálne systémové zdroje. Ako lákadlo je tým
pádom možné použiť už vyradený alebo low–end systém.
Podobne ako ostatné bezpečnostné riešenia, tak aj technológia na báze lákadiel, má špecifické
nevýhody [1]:



Obmedzené videnie (limited view) – jediným spôsobom, kedy Honeypot dokáže aktivity
útočníka zachytiť a sledovať, je ten keď s ním útočník priamo komunikuje. Útoky na ostatné
časti systému nebudú zaznamenané, pokiaľ nebude Honeypot tiež ohrozený.
Prezradenie identity Honeypotu (discovery and fingerprinting) – Honeypot má určité
očakávateľné vlastnosti alebo správania, kvôli ktorým útočník môže zistiť skutočnú totožnosť
lákadla. Aj jednoduchá chyba, ako je nesprávne napísané slovo v emulácii služby, môže byť
pre útočníka signálom interakcie s Honeypotom [8].
Riziko prevzatia (risk of takeover) – ak nad Honeypotom získa útočník kontrolu, môže ho
zneužiť pri útoku na iné systémy vo vnútri alebo mimo organizácie.
4 ARCHITEKTÚRA
SYSTÉMU
HYBRIDNÝ HONEYPOT
DETEKCIE
VYUŽÍVAJÚCA
Hlavnú slabinu IDS predstavuje problém pri detegovaní nového typu útoku, ako aj použitie odlišnej
stratégie pri útoku alebo nového nástroja. Aby bolo možné zachytiť aj takéto útoky je nutné každý
nový útok zaznamenať do konfiguračnej databázy IDS. Navrhovaný systém detekcie využíva
sofistikovaný hybridný Honeypot pre zníženie záťaže pri budovaní a navrhovaní bezpečnostných
prvkov distribuovaných systémov a rozsiahleho zhromažďovania dát, ako aj minimalizovanie
ktorejkoľvek hrozby prieniku do systému. Hybridný Honeypot kombinuje niekoľko nástrojov (Snort,
Dionaea a Sebek) pracujúcich ako jeden celok. Kvôli rýchlej odozve na daný útok navrhovaný systém,
znázornený na Obr. 19, analyzuje všetky zachytené dáta v rôznych formátoch. Pri výskyte/začatí
49
interakcie s Honeypotom zároveň poskytuje, prostredníctvom webového rozhrania, aj varovný systém
správ pre systémového administrátora.
integrácia dát
a analýza dát
prijímanie správ
server
zhromažďovanie
dát
rýchle
rozmiestnenie
klient
klient
architektúra systému
útok na systém
útok na systém
Obr. 3 Architektúra navrhovaného systému detekcie.
Navrhovaná architektúra pozostáva z niekoľkých klientov a servera. Klient zhromažďuje informácie o
útoku a zachytený škodlivý kód následne odosiela späť na server. Server zaznamená a analyzuje útok,
vydá varovanie a pomocou webového rozhrania zobrazí celkovú informáciu. Architektúra je navrhnutá
na dosiahnutie efektu centralizovaného riadenia distribuovaných informácií a vybudovania
kompletného distribuovaného systému včasného varovania.
4.1 ARCHITEKTÚRA – KLIENT
Z dôvodu zhromažďovania dát o útočníkových aktivitách počas samotného útoku sú nainštalovaní
klienti umiestnení v rovnakej doméne. Pri kyberútoku sa, v závislosti od typu, aktivujú rôzne súčasti
systému pre zber množiny dát a ich spätné doručenie serveru na uľahčenie následnej analýzy a pre
následné aktualizovanie systémovej bezpečnosti. Architektúra klienta, zobrazená na Obr. 4, pozostáva
z troch súčastí:
Snort – monitoruje a filtruje pakety pri detegovaní prieniku. Identifikuje vzory jednotlivých útokov,
informácie a varovné správy.
Nepenthes klient – simulovaním všeobecných služieb a zraniteľných miest láka útočníkov, pričom
zachytáva vzory škodlivých kódov.
Sebek klient – zaznamenáva správanie útočníka počas interakcie s Honeypotom do logovacích
súborov.
50
Fanfara, Chovanec
server
Snort
Nepenthes
klient
Sebek
klient
zachytené
pakety
zachytený
malware
logovacie
súbory
klient
útoky na systém
Obr. 4 Architektúra klienta.
4.2 ARCHITEKTÚRA – SERVER
Z dôvodu centralizácie zozbieraných údajov je server súčasne pripojený k viacerým klientom
a nastavený prijímať všetky odosielané správy, ktoré následne ukladá do databázy. Architektúra
servera je znázornená na Obr. 5. Previazanosťou jednotlivých správ indikuje zámer útočníkov
napadnúť cielené oblasti počítačov rozsiahlymi útokmi alebo skenovaním. Navrhovaná architektúra
servera pozostáva z troch častí, ktoré ešte pred uložením do databázy absolvujú proces normalizovania
vstupných formátov:
Malware server – prijíma vzory malwaru odosielané časťou Nepenthes klient.
Sebek server – súčasne prijíma a filtruje viacero zdrojov dát predstavujúce inštrukciu alebo spojenie
odosielaných dát na uloženie.
Verifikácia – modulárny návrh open-source hybridného systému na detekciu prieniku, využívajúci
štandardný komunikačný formát. Dokáže sa prispôsobiť potrebám rozsiahleho systému z akéhokoľvek
bodu nasadenia, prijímať množstvo údajov od klientov a integrovať rôznorodé dátové formáty.
rozhranie
webového
manažovania
51
databáza
administrátor
proces normalizovania
malware server
Sebek server
verifikácia
malware
logovacie súbory
pakety vzdialeného systému
server
klienti
Obr. 5 Architektúra servera.
Webové rozhranie servera zobrazuje celú analýzu informácie o útoku, získanej z databázy. Súčasne
monitoruje útoky a výskyt neobvyklých okolností. V prípade ich výskytu sa zvýraznia konkrétne
správy, aby správca systému dokázal správne a včas reagovať. Najideálnejšie riešenie predstavuje
koncept použitia navrhovaného autonómneho sofistikovaného Honeypotu pre proces detegovania.
4.3 NÁVRH SOFISTIKOVANÉHO HONEYPOTU
4.3.1
IDEÁLNY STAV
Riešenie súčasného stavu predstavuje návrh sofistikovaného Honeypotu, ktorý funguje na princípe
plug-&-play. Optimálny stav nastáva, ak po zapojení lákadlo vykoná všetky konfigurácie úplne
samostatne. Napr. po nainštalovaní OS Linux do distribuovaného systému, budeme mať linuxový
Honeypot, alebo pri odstránení ľubovoľnej služby, sa súvisiaca služba odstráni aj spomedzi zoznamu
emulovaných služieb. Pri výmene smerovačov, napr. Hewlett-Packard za smerovače Cisco, sa lákadlo
tváriace ako smerovač samostatne nakonfiguruje a aktualizuje.
Riešením je zariadenie, ktoré jednoducho stačí len pripojiť do siete a samé sa naučí topológiu
systému, presne určí počet Honeypotov, ako aj ich konfiguráciu a dokáže sa v reálnom čase adaptovať
na akúkoľvek zmenu v systéme.
4.3.2
PROBLÉM
Prvou a najkritickejšou časťou sofistikovaného Honeypotu je spôsob, akým dokáže získavať
informácie o sieti, v ktorej je nasadený, napr. aké systémy sú využívané a ako sa používajú v danom
prostredí – znázornené na Obr. 6. Po získaní týchto parametrov bude sofistikovaný Honeypot
52
Fanfara, Chovanec
inteligentne mapovať a promptne reagovať na dané prostredie. Jeden z možných a najjednoduchších
spôsobov je použiť aktívne sondovanie a takto určiť používané systémy, ich typ i používané služby.
Použitím aktívnej metódy získavania údajov, ktorá má svoje nedostatky v podobe zvýšenej záťaže
siete, vzniká riziko ohrozujúce prevádzku systému.
servery s OS Linux
servery s OS Windows
databáza
sofistikovaný
Honeypot
smerovače
pasívne získavanie parametrov
klienti
distribuovaný systém
Obr. 6. Pasívne získavanie systémových parametrov sofistikovaným Honeypotom pre determinovanie spôsobu
rozmiestnenia virtuálnych Honeypotov.
Pre kontinuálnu a korektnú funkčnosť v distribuovanom systéme by sofistikovaný Honeypot musel
neustále aktívne skenovať celé prostredie nasadenia, čo nepredstavuje najvhodnejší prístup.
4.3.3
RIEŠENIE PROBLÉMU
Riešením nevýhod aktívneho skenovania predstavuje pasívny prístup, konkrétne metóda pasívneho
získavania odtlačkov a mapovania (passive fingerprinting and mapping) [13].
Metóda pasívneho získavania odtlačkov nie je nová. Ideou je zmapovanie a získanie prehľadu
systémov v nasadenom prostredí. Rozdiel oproti aktívnej metóde predstavuje spôsob mapovania, ktorý
je pasívne získavaný odchytávaním sieťovej komunikácie, jej analyzovaním a následným určením
identity systémov. Pasívny spôsob používa rovnaké metódy ako aktívny. Nástroje ako, napr. Nmap
[13], vytvoria databázu signatúr o známych operačných systémoch a službách. Po vytvorení databázy
tieto nástroje aktívne vysielajú pakety, vyžadujúce odpoveď, od cieľových zariadení. Prichádzajúce
odpovede, unikátne pre väčšinu operačných systémov a služieb, sú porovnávané s databázou z dôvodu
jednoznačného identifikovania operačného systému a používaných služieb.
53
Pasívne získavanie odtlačkov používa rovnaký prístup ako vyššie popísaná databáza, ibaže dáta
získava pasívne. Namiesto aktívneho sondovania systému odchytáva prevádzku zo siete a analyzuje
odchytené pakety, ktoré následne porovnáva s databázou signatúr identifikácie vzdialeného systému.
Metóda pasívneho získavania odtlačkov nie je limitovaná použitím výhradne TCP protokolu, čo
umožňuje využitie iných protokolov. Tým, že je metóda kontinuálna – zmeny v sieti zachytáva
v reálnom čase, sa jej výhoda stáva kritickou pre udržiavanie realistického Honeypotu počas dlhého
obdobia. Jedinú nevýhodu pre pasívne získanie predstavuje správnosť fungovania cez smerované siete
– efektívnejšie je pri použití v lokálnych sieťach.
4.3.4
KONCEPT
Navrhovaný Honeypot používa pri získavaní údajov o sieti koncept založený na pasívnom získavaní
odtlačkov. Honeypot je nasadený ako samostatné zariadenie, ktoré je fyzicky pripojené do počítačovej
siete distribuovaného systému. Pasívnym analyzovaním sieťovej prevádzky determinuje počet
používaných systémov, typ operačných systémov, druh spustených a poskytovaných služieb, po
prípade zistí, s kým a ako často komunikuje konkrétny systém. Tieto informácie slúžia pre mapovanie
a získanie znalostí o sieti. Akonáhle Honeypot zozbiera všetky potrebné informácie, môže začať
s rozmiestňovaním Honeypotov Obr. 7, ktoré sú vytvorené pre zrkadlenie celého systému. Honeypoty
so schopnosťou výzoru a správania sa rovnakým spôsobom ako produkčné prostredie, dokážu bez
problémov splynúť s okolím, čo robí ich identifikáciu alebo vypátranie útočníkom omnoho
zložitejším. Pasívne získavanie informácií však nekončí, ale prebieha kontinuálne, čím monitoruje
celú sieť systému a predstavuje zvýšenie flexibility, nakoľko pri akejkoľvek zmene je táto v reálnom
čase identifikovaná a, v systéme rozmiestnenými Honeypotmi, v čo najrýchlejšom čase realizovaná.
4.3.5
ROZMIESTNENIE HONEYPOTOV V SYSTÉME
Tradičné riešenie otázky implementovania lákadlá do systému vyžaduje jeho fyzické umiestnenie pre
každú monitorovanú IP adresu, čo predstavuje značné časové obdobie i prácu. Jednoduchším
autonómnym riešením, napr. typu vystreľ a zabudni (fire-&-forget), je neimplementovať fyzické
Honeypoty, ale virtuálne, ktoré v dostatočnom množstve dokážu monitorovať všetky nevyužívané IP
adresy. Virtuálne lákadlá sledujú identický IP adresný priestor, ako samotný systém. Všetky virtuálne
lákadlá sú vytvorené, umiestnené a spravované jedným fyzickým zariadením – navrhovaným
sofistikovaným Honeypotom, ktorého princíp fungovania je znázornený na Obr. 7.
Nakoľko virtuálne Honeypoty monitorujú nevyužívané IP adresy v počítačovej sieti, je takmer isté, že
akákoľvek aktivita daných IP adries je z najväčšou pravdepodobnosťou škodlivým alebo
neautorizovaným správaním. Pomocou informácií získaných prostredníctvom pasívneho mapovania
prostredia je možné stanoviť potrebné množstvo, typ a rozmiestnenie Honeypotov.
Schopnosť dynamicky vytvárať a rozmiestňovať virtuálne lákadla už existuje. Open-source riešenie
Honeypotu s nízkou interakciou – Honeyd umožňuje nasadiť virtuálne lákadlá v celom prostredí
organizácie. Kombináciou možností riešenia ako je Honeyd a schopnosťami metódy pasívneho
získavania odtlačkov, je možné realizovať návrh autonómneho sofistikovaného Honeypotu
s dynamickým vytváraním a rozmiestňovaním virtuálnych lákadiel, ktoré splynutím s okolitým
prostredím systému minimalizujú riziko identifikovania a odhalenia útočníkom [14].
54
Fanfara, Chovanec
servery s OS Linux
servery s OS Windows
databáza
sofistikovaný
Honeypot
smerovače
klienti
pasívne získavanie
parametrov
distribuovaný systém
Obr. 7. Rozmiestnenie virtuálnych Honeypotov na základe získaných parametrov.
5 ZÁVER
V súčasnosti je bezpečnosť informačných technológií obzvlášť dôležitá v spoločnostiach, ktoré sú
závislé od informácií. Preto sa, pri tvorbe systémov, kladie nemalý dôraz práve na ochranu údajov
a informačných zdrojov. Ochrana prístupu, dostupnosť a integrita údajov reprezentujú základné
bezpečnostné vlastnosti požadované od informačných zdrojov. Narušenie niektorej z uvedených
vlastností by znamenalo prienik do systému a s tým súvisiace bezpečnostné riziko. Existuje niekoľko
spôsobov ochrany systémov, kam radíme aj rôzne metódy na zabezpečenie, obsahujúce bezpečnostné
pravidlá a popisujúce jednotlivé úrovne možného správania.
Ďalším spôsobom obrany sú rôznorodé systémy, ktoré detegujú neobvyklé a podozrivé správanie.
Medzi tieto systémy zahŕňame aj systémy na detekciu prienikov. Pri systémoch na detekciu prienikov
predstavuje hlavný problém riziko nedetegovania prieniku.
Riešením daného problému detekcie predstavuje použitie lákadiel, ktoré sú relatívne novou, čoraz
populárnejšou a používanejšou, technológiou. Technológia nazývaná Honeypot má obrovský
potenciál pre bezpečnostnú komunitu a môže dosiahnuť niekoľko cieľov iných technológií, čo ju robí
takmer univerzálnou. Použitie lákadiel predstavuje cenovo-efektívne riešenie pre zvýšenie
bezpečnostného postavenia organizácie. Z tohto dôvodu sú rastúcou mierou nasadzované v systémoch,
avšak väčšinou pasívne, nakoľko administrátori sledujú situáciu v systéme a akonáhle bol Honeypot
napadnutý, manuálne vykonajú analýzu a implementujú riešenie.
55
Tak ako akákoľvek nová technológia, aj lákadlá majú určité nedostatky, ktoré potrebujú prekonať
a odstrániť. Takže ani Honeypot nepredstavuje všeliek na prelomenie bezpečnosti. Vzhľadom k tomu,
že sa používa na zber informácií o útočníkoch a iných hrozbách, je užitočný ako nástroj pre forenzné
činnosti v sieti a detekciu prienikov v počítačových systémoch.
Budúcnosť Honeypotov a počítačovej bezpečnosti v detekcii prienikov predstavujú sofistikované
lákadlá, pretože majú predpoklad radikálnej revolúcie autonómneho nasadenia a údržby. Študovaním
a monitorovaním siete v reálnom čase, sa stávajú vysoko-flexibilným riešením. Nielenže ich nasadenie
a spravovanie sa stáva cenovo efektívnejším, ale poskytuje aj omnoho lepšiu integráciu do systému,
čím sa minimalizuje riziko chyby ľudského faktora počas manuálneho konfigurovania. Splynutím
s okolitým prostredím systému navyše minimalizuje riziko identifikovania útočníkom.
POĎAKOVANIE
Táto práca bola podporovaná Agentúrou na podporu výskumu a vývoja na základe zmluvy
č. APVV-0008-10 (50%) a vznikla aj vďaka podpore v rámci operačného programu Výskum a vývoj
pre projekt: Centrum výskumu účinnosti integrácie kombinovaných systémov obnoviteľných zdrojov
energií, s kódom ITMS: 26220220064, spolufinancovaný zo zdrojov Európskeho fondu regionálneho
rozvoja (50%).
6 ZOZNAM POUŽITÝCH ZDROJOV
[1]
MCGRAW, Gary a Greg MORRISETT. Attacking Malicious Code: A Report to the Infosec
Research Council. IEEE Software: A report to the Infosec Research Council. 2000, vol. 17,
issue 5, s. 33-41. DOI: 10.1109/52.877857.
[2]
MCHUGH, John, Alan CHRISTIE a Julia ALLEN. Defending Yourself: The Role of
Intrusion Detection Systems. IEEE Software: A report to the Infosec Research Council. 2000,
vol. 17, issue 5, s. 42-51. DOI: 10.1109/52.877859.
[3]
Know your enemy: revealing the security tools, tactics, and motives of the blackhat
community. Boston: Addison-Wesley, c2002, xvii, 328 s. ISBN 02-017-4613-1.
[4]
Snort. [online]. [cit. 2013-03-03]. Dostupné z: http://www.snort.org.
[5]
CHUVAKIN, Anton. “Honeynets: High Value Security Data”. Network Security. 2003, vol.
2003, issue 8, s. 11-15. DOI: 10.1016/S1353-4858(03)00808-0.
[6]
Symantec Corporation. SPITZNER, Lance a Marty ROESCH. The Value of Honeypots: Part
One: Definitions and Values of Honeypots [online]. 2001, 3.11.2010 [cit. 2013-03-03].
Dostupné z: http://www.symantec.com/connect/articles/value-honeypots-part-one-definitionsand-values-honeypots.
[7]
KECIA, Gubbels. Hands in the Honeypot. In: SANS Institute: InfoSec Reading Room [online].
2002 [cit. 2013-06-03]. Dostupné z:
http://www.sans.org/reading_room/whitepapers/detection/hands-honeypot_365.
[8]
SPITZNER, Lance. Honeypots tracking hackers. Boston: Addison-Wesley, 2003, xxvi, 452 s.
ISBN 03-211-0895-7.
56
[9]
Fanfara, Chovanec
BAECHER, Paul, Markus KOETTER, Thorsten HOLZ, Maximillian DORNSEIF a Felix
FREILING. The Nepenthes Platform: An Efficient Approach to Collect Malware. s. 165. DOI:
10.1007/11856214_9.
[10]
BAUMANN, Reto a PLATTNER. White Paper: Honeypots. 2002. Dostupné z:
http://www.rbaumann.net/download/whitepaper.pdf.
[11]
SPITZNER, L. a PLATTNER. The honeynet project: trapping the hackers. IEEE Security.
2003, vol. 1, issue 2, s. 15-23. DOI: 10.1109/MSECP.2003.1193207.
[12]
SINGH, Ram Kumar a T. RAMANUJAM. Intrusion Detection System Using Advanced
Honeypots. (IJCSIS) International Journal of Comput er Science and Info rmation Security
[online]. 2009, roč. 2, č. 1 [cit. 2013-06-03]. Dostupné z:
http://arxiv.org/ftp/arxiv/papers/0906/0906.5031.pdf.
[13]
LYON, Gordon Fyodor. Nmap network scanning: official Nmap project guide to network
discovery and security scanning. 1st ed. Sunnyvale, CA: Insecure.Com, LLC, c2008, xxix,
434 p. ISBN 09-799-5871-7.
[14]
PROVOS, Niels. Honeyd: A Virtual Honeypot Daemon. Dostupné z:
http://www.citi.umich.edu/u/provos/papers/honeyd-eabstract.pdf.
[15]
Symantec Corporation. In: SPITZNER, Lance. Open Source Honeypots: Learning with
Honeyd [online]. 2003, 2.11.2010 [cit. 2013-06-03]. Dostupné z:
http://www.symantec.com/connect/articles/open-source-honeypots-learning-honeyd.
[16]
SUTTON, Raplh Edvard Jr. Section 1: How to Build and Use a Honeypot. In: Docstoc:
Documents & Resources for Small Businesses & Professionals [online]. 2008 [cit. 2013-0603]. Dostupné z: http://www.docstoc.com/docs/1953205/How-to-build-and-use-a-HoneypotBy-Ralph-Edward-Sutton-Jr-DTEC.
[17]
BALAZ, Anton a Liberios VOKOROKOS. Intrusion detection system based on partially
ordered events and patterns. 2009 International Conference on Intelligent Engineering
Systems. IEEE, 2009, s. 233-238. DOI: 10.1109/INES.2009.4924768.
[18]
VOKOROKOS, Liberios, Norbert ÁDÁM a Anton BALÁŽ. Application Of Intrusion
Detection Systems In Distributed Computer Systems And Dynamic Networks [online]. Košice,
2008[cit. 2013-03-03]. ISBN 978-80-8086-100-1. Dostupné z:
http://kpi1.fei.tuke.sk/CST08/CSetTRS08.pdf#page=23.
2(1), 2013, 57–69, DOI: 10.18267/j.aip.13
Online: aip.vse.cz
Sekce / Section:
Vizuální jazyk Archimate pro modelování Enterprise
architektury na příkladu integrace ekosystému tabletu
Hynek Stehlík1
1
Vysoká škola polytechnická Jihlava, Tolstého 16, Jihlava
[email protected]
Abstrakt: Účelem článku je ukázat možnosti modelování Enterprise architektury
prostřednictvím vizuálního jazyka Archimate na problému integrace existujících
podnikových technologických architektur a nových technologií tabletů, které spolu
s doprovodnými webovými službami představují nové typy ekosystémů IT
orientovaných na uživatele jako konzumenty. Diskutován je zejména tlak na další
nárůst heterogenního prostředí při nasazování aplikací v podnikových systémech.
Článek je primárně určen pro architekty IT a manažery v podnikové sféře, kteří
jsou zapojeni do strategických rozhodování.
Klíčová slova: Archimate, tablet, architektura, podnikové informační systémy,
ekosystém
Title: Visual language Archimate for Enterprise Architecture modelling
– an example of a tablet ecosystem integration
Abstract: The purpose of this article is to demonstrate Enterprise Architecture
modelling capabilities of Archimate – a visual language. We analyse problem of an
integration of a consumer oriented tablet ecosystem into existing enterprise
technology architectures. We discuss forces leading towards an increase
of heterogeneous environment during deployment of tablet applications into
enterprise systems. The article is primarily targeted at IT architects and managers
in the enterprise sector, who are involved in strategic decision processes.
Keywords: Archimate, Tablet, Architecture, Enterprise Information Systems,
Ecosystem
58
Stehlík
1 ÚVOD
Rozhodování o změnách v architektuře podnikových informačních technologií (IT) stále častěji
spadají mezi strategická rozhodování podniků. Komplexnost dosavadních technologií IT se v současné
době nesnižuje, spíše naopak. V posledních letech například vyrostl zcela nový trh zaměřený na
domácí uživatele chytrých telefonů a tabletů, kteří se stávají konzumenty nových generací
internetových služeb. Tento trend logicky proniká i do podnikového prostředí, ale často se tak děje
nekoordinovaným způsobem. Cílem příspěvku je ukázat možnosti modelování podnikové architektury
prostřednictvím vizuálního jazyka Archimate na problému integrace existujících architektur s novými
architekturami, které přicházejí do podniků s tablety.
Účelem příspěvku není zásadní hodnocení technologií uváděných v diagramech a komplexní přehled
alternativ, ale především předvedení možností různých pohledů na architekturu prostřednictvím
grafického jazyka Archimate. Představuje rozšíření příspěvku předneseného na konferenci Trendy
a technologie, která se konala na Vysoké škole polytechnické Jihlava [10].
2 STANDARD ARCHIMATE – GRAFICKÝ PROSTŘEDEK PRO
ZNÁZORNĚNÍ HLAVNÍCH ASPEKTŮ PODNIKOVÝCH
ARCHITEKTUR
V oblasti podnikových IT existuje nepřeberné množství pojmů a označení, které se zhruba 40 let
postupně vyvíjelo poměrně nezávisle v rámci geneze jednotlivých technických disciplín. Často
odlišnou terminologii používají specialisté vývoje aplikací, administrátoři platforem, správci sítí,
architekti internetových technologií. Současně jsou pro podporu procesů řízení IT vytvářeny
specifické metodologie a nástroje, které taktéž zavádějí různé termíny (ITIL, COBIT apod.). Stává se,
že stejný výraz má ve dvou disciplínách jiný význam (sémantiku).
Tento stav komplikuje vzájemné porozumění různých technických týmů navzájem, nemluvě
o porozumění mezi technickými a obchodními (byznys) týmy. Týmy, které jsou primárně zodpovědné
za rozvoj a provoz IT, používají bohužel příliš často svoje technické dialekty, zatímco obchodní týmy
potřebují mluvit především jazykem obchodních procesů, produktů a služeb.
Dosavadním standardním podnikovým řešením je zavedení striktního procesu zadávání požadavků
a změn, ve kterém je odděleno prvotní zadávání funkčních požadavků na systémy IT od následného
návrhu a implementace řešení IT. Pro samotný návrh konceptu aplikačního systému a vlastní
programování jsou používány propracované a osvědčené metodiky, například RUP a UP.
Jak se ale ukazuje, oblasti byznysu a technologické oblasti IT jsou natolik provázány, že návrh
konceptů (architektur) je nutné provádět z hlediska celkového pohledu na podnik. Tímto úkolem se
zabývá disciplína Enterprise Architecture (EA, český překlad se zatím neustálil na jednotném
termínu). Existující standard ISO 42010 pro popis architektur [6] definuje základní pojmy (hledisko,
pohled, rámec) v a představuje tak velmi kvalitní základ pro popis architektury podnikových systémů.
Z českých zdrojů je velmi kvalitně popsáno zahrnutí tohoto standardu do širšího kontextu EA v článku
autorů VŠE [3].
59
Archimate [2] je nový standard pro modelování Enterprise architektury, který je velmi přehledný jak
pro manažery, tak pro architekty IT a tím usnadňuje tvorbu společných týmů. Je založen na standardu
ISO 42010. Je dnes již zahrnut i ve většině profesionálních softwarových nástrojů pro modelování
architektury. Přehled komponent jazyka použitých v tomto článku (relací a konceptů) a jejich notace
obsahuje následující tabulka.
RELACE
NOTACE
KONCEPT
NOTACE KONCEPT
Association
(asociace)
Business actor
(byznys aktér)
Application service
(aplik. služba)
Used by
(využíváno)
Business role
(byznys role)
Application
component (aplik.
komponenta)
Realization
(realizace)
Business process
(byznys proces)
Flow (tok)
Business
function (byznys
funkce)
System software
(systémový software)
Triggering
(spouštění)
Business service
(byznys služba)
Device (zařízení)
Grouping
(seskupování)
Meaning
(význam)
Specialization
(specializace)
Product
(produkt)
NOTACE
Infrastructure service
(infr. služba)
Artifact (artefakt)
Tab. 1. Vybrané komponenty jazyka Archimate.
Na obrázku 1 je uveden zjednodušený diagram základních procesů životního cyklu obchodní aplikace
vytvořený v nástroji ARCHI [8]. Cyklus začíná procesem zadání obchodních požadavků, následuje
vývoj nebo nákup aplikace a její testy, nakonec je aplikace distribuována k nasazení do provozu
a podnikový uživatele s ní může pracovat. Pro zjednodušení není uváděna žádná organizační struktura,
ale pouze podnikové funkce, které je nutné zajistit (řízení obchodních činností, řízení, vývoj a provoz
IT). Je uvažován nejrozšířenější technologický koncept, kdy na přístupových PC je instalován systém
Microsoft Windows.
60
Stehlík
Obr. 1. Příklad využití jazyka Archimate pro zobrazení životního cyklu aplikace.
Obrázek zároveň ukazuje tradiční model aplikací typu klient-server, který se masově rozšířil po
nástupu PC a je stále využíván. Úskalím tohoto modelu je nutnost distribuce a instalace aplikací na
koncová PC, která jsou mnohdy rozšířena v geograficky vzdálených lokalitách.
2.1 APPLE IPAD JAKO ZAČÁTEK
KONZUMNÍCH SLUŽEB
EXPANZE
NOVÉ
GENERACE
Technologie osobních digitálních asistentů (PDA) se nejprve vyvíjely jako off-line zařízení (např.
Microsoft Pocket PC), do kterých bylo možné instalovat aplikace prostřednictvím připojení k PC. Po
prudké expanzi telefonů GSM docházelo k integraci funkcí telefonů do zařízení typu PDA. Vzhledem
k různorodosti zařízení a zastaralému konceptu se tato zařízení obtížně uplatňovaly principy centrální
správy a konfigurace, které jsou vyžadovány v rozsáhlém podnikovém prostředí.
Průlomová byla architektura Blackberry od firmy RIM, která byla postavena jako služba mobilního
emailu pro podnikové prostředí. Architektura systému byla od začátku navrhována tak, aby veškerou
konfiguraci koncových telefonů včetně nastavení zabezpečení bylo možné provádět centrálně
z jednoho místa prostřednictvím software pro centrální správu a zabezpečit tak ochranu podnikových
dat.
61
V této situaci roku 2007 firma Apple uvedla na trh telefon iPhone a následně v roce 2010 zcela nový
typ tabletu iPad, které zásadně změnily situaci nejen na celém trhu s chytrými telefony, ale i na trhu
s osobními počítači, protože nový tablet začal částečně konkurovat notebookům.
Nejdůležitější aspekty jejich nástupu jsou dle mého názoru následující (stranou ponecháváme
špičkový design a promyšlený produktový marketing):
1. Revoluční ovládání zařízení prsty prostřednictvím gest na dotykové obrazovce (není potřeba
používat stylus)
2. Zařízení je dodáváno jako jeden celek se službami systémové aktualizace a instalace aplikací,
které jsou jednotné a umístěné u poskytovatele. Celek je propojen do jednoho obchodního
modelu se službami prodeje obsahu (hudba, video) a aplikací.
To je doprovázeno principem maximální jednoduchosti ovládání a principem zamezení přímého
přístupu uživatele k funkcím operačního systému.
Druhý aspekt si můžeme znázornit prostřednictvím modelů Archimate – obrázky 2 a 3.
Obr. 2. Společná architektura iPhone a iPad – zařízení a služby představují jeden produkt.
Systémový princip návrhu postavený na konceptu černé skříňky (blackbox) a jejího rozhraní je zde
dotažen téměř k dokonalosti. Rozhraní pro uživatele je maximálně zjednodušeno, vše ostatní je
posunuto do transparentních služeb. Například z konfigurace operačního systému je dostupné jen
nezbytně nutné minimum, aby uživatel nemohl nic důležitého pokazit, a souborový systém je dokonce
odstraněn z přímého vlivu uživatele - je poskytnut pouze prostřednictvím jednotlivých aplikací.
Další obrázek ukazuje vztah mezi koncovými službami pro uživatele (prvky byznys vrstvy jsou žluté)
a komponentami a službami aplikací (prvky aplikací modře). Zelená zůstává pro prvky technologie
infrastruktury.
62
Stehlík
Obr. 3. Tablet z pohledu uživatele (zjednodušeno).
V rámci procesu dodávky (provisioningu) aplikace (Apple [1]) musí být kód aplikace nejprve být
dodán dodavateli, kde projde procesem certifikace (neznázorněno), a teprve pak je zpřístupněn
uživatelům jako produkt, který je možné si zakoupit, stejně jako jsou nabízeny hudební tituly a videa.
Po zakoupení proběhne automatická distribuce samotného kódu aplikace a její instalace na tablet,
která je pro uživatele prakticky transparentní. Od toho okamžiku aplikace může začít fungovat jako
samostatná služba pro uživatele, její napojení na další internetové služby pro přehlednost již není
zobrazeno.
Na obrázcích 2 a 3 je jazyk Archimate použit volněji: smyslem je vizuálně zdůraznit propojení
zařízení se službami, které poskytuje. Uvedený příklad zároveň ilustruje možnosti notace Archimate,
která dovoluje zjednodušit pohledy na architekturu a zároveň ponechat ty nejdůležitější aspekty. Díky
konceptu zobrazení služeb a jejich vztahů k ostatním entitám model umožní zachovat celostní
(holistický) přístup k architektuře. Relace „realizuje“ umožňuje znázornit způsob, jak jsou
z jednotlivých komponent (systémy, aplikace) vytvářeny služby. S narůstajícím posunem podnikových
architektur od interních technologií IT k provázanosti interních a externích služeb je Archimate velmi
vhodná alternativa, protože nabízí jednotnou notaci pro zobrazení integračních pohledů při
modelování Enterprise architektury.
3 EKOSYSTÉMY A JEJICH ODLIŠNOSTI
Tablet v novém pojetí tedy představuje celý ekosystém vystavěný s cílem zajištění integrity
end-to-end (od tabletu jako koncového zařízení přes služby až k jednomu bodu kontroly integrity
– vstupnímu bodu pro vývojáře). To je zásadní změna proti celým předcházejícím generacím
mobilních telefonů a tabletů – dosud byl koncový uživatel sám zodpovědný za integritu zařízení (na
63
obrázku 2 vlevo) - instaloval si sám aplikace na vlastní odpovědnost lokálně. V novém pojetí se
přesouvá hlavní odpovědnost za integritu celého ekosystému (včetně koncového zařízení) na
dodavatele ekosystému (někdy označován jako megavendor) a možnosti lokálních zásahů uživatele
jsou omezeny.
Řada z těchto principů je velmi blízká správcům podnikových systémů právě proto, že tento koncept
výrazně minimalizuje náklady na správu samotných koncových zařízení.
Na konceptuální úrovni to je tedy podobný koncept, jaký se v oblasti PC ustálil ve velkých
podnikových IT systémech pod názvem prostředí řízeného desktopu (managed desktop environment),
ve kterém jsou aplikace na koncová PC dodávány z centrálního místa. Významným rozdílem je ale
způsob aktivace samotné instalace: zatímco v podnikových systémech převládala centrálně aktivovaná
instalace na PC (metoda push - viz procesy na obrázku 1), v tabletových systémech je výběr a aktivace
aplikací ponechána na samotném uživateli (metoda pull).
Důvodem je, že rozvoj tabletového ekosystému je řízen megavendorem především s důrazem na
úspěšnost služeb na konzumním trhu. Trh podnikového IT nepředstavuje v první etapě zdaleka takový
potenciál obratu, proto jej první generace tabletových systémů spíše opomíjejí. Tabulka 2 zobrazuje tři
nejvýznamnější megavendory a hlavní součásti jejich ekosystémů pro tablety.
MEGAVENDOR
PRODUKT
PLATFORMA
HLAVNÍ SLUŽBA
Apple
iPad
iOS
App Store
Google
Různí dodavatelé
Android
Google Play
Microsoft
Surface RT + různí
dodavatelé
Windows RT, CPU ARM
Microsoft Store
Surface Pro + různí
dodavatelé
Windows 8, CPU Intel
Microsoft Store
Tab. 2. Hlavní součásti ekosystémů pro tablety.
V této situaci podniky, jejichž architektura IT je v oblasti koncových zařízení většinou založena na
platformě Windows, hledají obvykle dva typy řešení pro tablety:
1. jaký typ aplikace zvolit pro zákazníky,
2. jak reagovat na poptávku po tabletech ze strany zaměstnanců podniku.
Obě řešení mají jiný kontext, priority a požadavky na integraci. Aplikace pro zákazníky jsou
navrhovány především v kontextu trhu a v návaznosti na serverové aplikační služby poskytované
podnikem, ale není nutno řešit další integraci na úrovni interního podnikového ekosystému. Příklad
případové studie tvorby aplikace pro tablet v bankovním prostředí uvádí Forrester [4].
Požadavky na nasazení aplikací pro tablet a zaměstnance je třeba analyzovat v kontextu stávajícího
podnikového ekosystému (systémy a procesy správy zařízení a software) a podnikové bezpečnostní
politiky. Tam, kde jsou vysoké požadavky na zabezpečení, je třeba hledat vyhovující model správy
64
Stehlík
tabletu a aplikací. Většinu dosavadních operačních systémů pro tablety představují systémy vyvinuté
pro mobilní telefony, které svým technickým konceptem i způsobem začlenění do ekosystému
megavendora většinou neumožňují, aby podniky převzaly jejich řízení způsobem obvyklým z řízení
desktopů.
Zatím jedinou významnou výjimku představují tablety založené na Windows 8, protože vycházejí ze
plnohodnotného desktopového systému Windows 7, pro který existuje řada osvědčených systémů
centrální správy. Podniky by tedy v případě požadavků na tablety pro zaměstnance měly analyzovat,
zda a jak tablety s Windows 8 (včetně aplikací pro styl METRO) je možné centrálně spravovat
a konfigurovat pomocí jejich dosavadních nástrojů na správu. Základní technické koncepty k této
problematice jsou uvedeny ve zdroji [9].
4 PROFILOVÁNÍ ROLÍ UŽIVATELŮ SYSTÉMŮ
Vznik nové generace mobilních služeb, které jsou postaveny na dotykových telefonech a tabletech
a doprovázeny rozšiřováním internetových služeb, je doprovázen nástupem nové generace uživatelů
jako konzumentů. Z dosavadních uživatelů domácích PC se stali uživatelé skutečně mobilní, kteří
často očekávají a někdy vyžadují stejné parametry mobilního přístupu k podnikovým informačním
systémům ze stejného zařízení.
Vzniklou situaci pak může charakterizovat následující diagram na obrázku 4.
Obr. 4. Dnešní člověk a dvě z jeho rolí z pohledu IT.
Člověk v roli konzumenta je zvyklý na aktivity, jako je sociální sdílení a spoluprožívání
prostřednictvím Facebooku, nákupy, hraní her, procházení internetu bez omezení, poslech hudby a vše
ostatní, nač jen pomyslí.
65
Naproti tomu od člověka v roli pracovníka se stále očekává, že se bude řídit podnikovými pravidly,
dodržovat bezpečnostní principy a především pracovat.
5 PODNIKOVÉ EKOSYSTÉMY PŘED
ZAVEDENÍ CENTRÁLNÍHO ŘÍZENÍ
IPAD
–
VE
ZNAMENÍ
Model nasazení aplikací typu klient-server (obr. 1) je v podnicích zhruba od začátku tisíciletí
nahrazován architekturou webových aplikací popřípadě architekturou centralizací aplikací na
terminálové servery – obrázek 5. Cílem obou novějších architektur je eliminovat potřebu distribuce
aplikací na vzdálená PC.
Architektura webových aplikací centralizovala aplikační logiku a slibovala ukončení potřeby
instalovat aplikace na koncová PC a zavedení nezávislosti na operačním systému koncového zařízení.
V architektuře terminálového serveru Windows (v nejpropracovanější podobě je dodávaná firmou
CITRIX) běží tradiční Windows aplikace na centrálním terminálovém serveru Windows (nebo spíše
na farmě serverů), ke kterému přistupuje buď specializovaný hardwarový terminál nebo terminálový
software instalovaný na PC.
V architekturách 2 a 3 tedy odpadá nutnost instalace byznys aplikací na vzdálené PC. Webový
browser a terminálový klient jsou fakticky také aplikace, ale svojí funkcí jsou blíže technické
infrastruktuře (proto jsou označeny tmavě zelenou barvou).
Obr. 5. Varianty dodávek aplikací v podniku.
Přestože na obrázku jsou architektury pro přehlednost zobrazeny odděleně, v reálném podniku se
většinou vyskytují minimálně první dvě z nich ve vzájemné provázanosti.
66
Stehlík
6 ARCHITEKTURY PROPOJENÍ – MOŽNÉ VARIANTY
Je třeba si uvědomit, že obchodní model typu iPad znovu oživil tradiční model tzv. tlustých aplikací,
které běží nativně na koncových zařízeních. Vznikl celý nový konzumní trh, který se opírá o dodávky
těchto aplikací z centrálních úložišť (obrázek 3).
Na první pohled nejsnáze je možné začlenit tablety do podnikových systémů napojením na webové
aplikace, jak je uvedeno na obrázku 6. Velmi ale záleží na typu podniku a jeho potřebě ochrany dat, je
tedy nutné nejprve provést konkrétní bezpečnostní analýzu.
Obr. 6. Jedna z variant propojení architektur prostřednictvím sdílené webové aplikace.
Pokud podnik disponuje architekturou terminálového serveru Windows, tak je možné uvažovat
o napojení tabletu prostřednictvím terminálového klienta (obrázek zůstane stejný, jen místo browseru
bude terminálový klient).
Nejnáročnější obvykle bude varianta integrace a využívání nativních (tlustých) aplikací tabletu, které
jsou uživateli nejvíce vyžadovány, protože zatím poskytují nejbohatší funkcionalitu:


67
znamená zavedení další nové aplikační platformy pro tablet
znamená zavedení dalšího typu distribuce aplikací
Pokud podnik potřebuje vytvářet vlastní aplikace pro tablety, měl by uvažovat o o využití nástrojů pro
tvorbu aplikací s HTML 5, které slibují nezávislost na platformě tabletu (a tedy i na ekosystému
megavendora).
7 NOVÁ ÚSKALÍ A NOVÉ MOŽNOSTI PRO PODNIKOVÉ ÚTVARY IT
Podnikoví pracovníci si ve svých druhých rolích privátních konzumentů rychle zvykli na vnímání IT
jako služby, kterou je velmi snadné vybrat, vyzkoušet a odložit. A to vše za velmi nízké ceny nebo
ještě častěji zadarmo. Je zřejmé, že podnikové IT takto z principiálních důvodů fungovat nemůže.
Různorodost (heterogenita) výpočetních systémů a aplikací obvykle bude přinášet vyšší náklady na
správu, než relativně stejnorodé prostředí. Podnik navíc vždy musí zajistit prioritně rozvoj, podporu,
stabilitu a bezpečnost svých hlavních procesů.
Poslední desetiletí zavádění procesních optimalizací IT orientovaných na služby (např. podle rámce
ITIL [7]) zajišťuje dosažení původních cílů, tedy větší transparentnost a přehlednost IT pro interní
zákazníky. Vedlejším efektem však často je, že interní zákazníci a management firmy mají dojem, že
IT je vlastně jenom služba a samotné technologie je nemusejí zajímat, s nimi už si musí poradit IT
samo. Opak je však pravdou.
V dané situaci je nezbytné, aby útvary IT byly schopny vysvětlovat služby IT jako celek, který je na
jednu stranu provázaný do obchodních služeb podniku a na druhou stranu do technologické
infrastruktury, která většinou založena na platformách (aplikační, databázové, systémové).
Standard Archimate představuje v současnosti jeden z nejkvalitnějších prostředků, který prozíravým
architektům podnikových systémů dává do ruky vizuální nástroj, ve kterém je možné konzistentně
zobrazit ty nejdůležitější aspekty vzájemných závislostí mezi podnikovými procesy, podnikovými
aplikacemi a technologickou infrastrukturou.
8 ZÁVĚRY A DOPORUČENÍ
8.1 SHRNUTÍ
Článek analyzuje nástup mediálních tabletů a souvisejících ekosystémů především z hlediska dodávky
aplikací a celkové architektury v kontextu vnitřních systémů podnikového IT. Zatímco tradiční životní
cyklus podnikové aplikace je převážně interní záležitostí (obrázek 1), architektura dodávek aplikací
v ekosystémech tabletů znamená posun těžiště správy operačního systému a distribuce aplikací mimo
samotný podnik (obrázek 3). Další zásadní změnou je nástup nových typů klientských aplikačních
platforem, které se převážně v podnikovém prostředí nevyskytovaly. Třetím faktorem a hlavním
driverem požadavků na změny jsou zaměstnanci-konzumenti (obrázek 4), kteří si zvykli na používání
tabletů v privátní sféře.
68
Stehlík
8.2 DOPORUČENÍ
Z hlediska architektury infrastruktury podnikových systémů se v této situaci se jeví jako nejvhodnější
integrační koncept sdílení centrálních webových aplikací popřípadě koncept připojení na terminálový
server (pokud jej podnik využívá) - viz obrázek 6. Velkou výhodou tohoto konceptu je zachování
dosavadních investic směrem k centralizaci aplikací. Nevýhodou může být menší uživatelská
přívětivost stávajících centrálních aplikací ve webovém prohlížeči na tabletu.
Jako logické řešení této situace lze doporučit zvážení tvorby firemních aplikací pro tabletová rozhraní
(ovládání gesty) s využitím nastupujícího standardu HTML 5, jehož podporu avizují všichni klíčoví
megavendoři. Toto řešení zároveň sníží závislost podniku na ekosystémech megavendorů a pomůže
oddálit případné strategické rozhodnutí při výběru platformy.
8.3 HLEDISKO ENTEPRISE ARCHITEKTURY
Primární ve vztahu k tabletům by mělo být hledisko vytvořené v procesu enteprice architektury, které
by se mělo opírat především o vyhodnocení skutečné obchodní potřeby na nasazení tabletů ve
vnitřních systémech. Byznys potřeba by měla být podložena reálnými funkčními požadavky na
tabletové řešení, na základě kterých je možné provést analýzu a vyhodnotit obchodní případ.
Podniky s velkým důrazem na bezpečnost, které zároveň využívají jako standardizovanou platformu
koncového zařízení Windows Desktop s centrálním systémem Active Directory, by měly zvážit tablet
s Windows 8, který kromě plnohodnotného operačního systému avizuje i možnost instalace aplikací
pro tablet s využitím stávajících technologií. V takovém případě by náklady na integraci správy tabletu
mohly být minimální. Pro seznámení s možnostmi technologií by pak podniky měly umět využít
řízený technologický experiment, který je provozován odděleně od stávajícího IT.
Jak jsem již zmínil, v oblasti nasazení tabletů je stále příliš brzo na stanovení dlouhodobé podnikové
strategie a výběr strategické platformy. Gartner [5] dává doporučení, kdy zvažovat přístup typu BYOD
(Bring Your Own Device) a jak přistoupit k systémům pro správu koncových zařízení v nové situaci.
V podstatě doporučuje na straně IT raději realisticky akceptovat a podporovat vybrané mobilní
platformy jako prevenci před živelným přístupem ze strany uživatelů. Podle mých zkušeností by však
ty podniky, kterým se podařilo díky standardizaci dosáhnout vysokou homogenitu svých interních
systemů, měly jen velmi opatrně zvažovat akceptaci dalších platforem orientovaných na konzumenty.
8.4 POPIS ARCHITEKTURY
Existence konzistentního popisu architektury IT v podniku je velmi žádoucí. Příklad uváděný ve
zřejmě první rozsáhlejší knize o implementaci Archimate [11] ukazuje, že standard Archimate je
možné ve velkém podniku použít i jako základní jazyk pro vytvoření kompletního aktuálního popisu
architektury podnikových systémů, který slouží zároveň jako databáze typu CMDB (Configuration
Management Database dle ITIL) pro navazující provozní procesy podnikového IT.
69
POZNÁMKA
Hodnocení a doporučení uvedená v příspěvku vycházejí z dlouholetých zkušeností autora s řízením
architektury rozsáhlých systémů a služeb IT v bankovním prostředí. Diagramy na obrázcích byly
vytvořeny ve volně dostupném nástroji ARCHI [7].
9 SEZNAM POUŽITÝCH ZDROJŮ
[1]
Apple. Distributing Apps. Dostupné z:
http://developer.apple.com/library/ios/documentation/Xcode/Conceptual/ios_development_wo
rkflow/35-Distributing_Applications/distributing_applications.html
[2]
The Open Group. ArchiMate 2.0 Specification. Dostupné z:
http://pubs.opengroup.org/architecture/archimate2-doc/toc.html
[3]
BUCHALCEVOVÁ, Alena, GÁLA, Libor. Architektura v podnikové informatice. Systémová
integrace, 2008, roč. 15, č. 3, s. 7–22. ISSN 1210-9479.
[4]
Forrester. Forrester Case Study: Citibank's Tablet App Transforms The Digital Banking
Experience. Dostupné z: http://www.forrester.com
[5]
GARTNER. Media Tablets and Beyond: The Impact of Mobile Devices on Enterprise
Management [online]. Gartner Inc., 30.1.2012, ID:G00230267. Dostupné z:
http://www.gartner.com/id=1909316
[6]
ISO/IEC 42010:2011, Systems and Software Engineering – Architecture description.
ISO/IEC, 2011
[7]
Information Technology Infrastructure Library (ITIL). Informace o zdrojích dostupné na:
http://www.itil-officialsite.com
[8]
Institute for Educational Cybernetics. ARCHI 2.3.1 [software]. Download dostupný z:
http://archi.cetis.ac.uk/download.html
[9]
Microsoft. Windows Assessment and Deployment Kit (ADK) for Windows 8. Dostupné z:
http://www.microsoft.com/en-us/download/details.aspx?id=30652
[10]
STEHLÍK, Hynek. ARCHIMATE – VIZUÁLNÍ JAZYK PRO MODELOVÁNÍ
ENTERPRISE ARCHITEKTURY NA PŘÍKLADU INTEGRACE TABLETU. In: Trendy a
technologie 2012. 1. vydání. Jihlava: VŠPJ, 2012, s. 31-38. ISBN 978-80-87035-63-4.
[11]
WIERDA, Gerben. Mastering Archimate: A Serious Introduction to Archimate Enterprise
Architecture Modelling Language. Edition I [online]. The Netherlands, 2012. ISBN 978-90819840-0-3. Dostupné z: http://masteringarchimate.com
2(1), 2013, 70–78, DOI: 10.18267/j.aip.14
Online: aip.vse.cz
Sekce / Section:
Jak žáci a učitelé českých škol využívají Internet
Václav Nádvorník1
1
Pedagogická fakulta, Jihočeská univerzita v Českých Budějovicích
Jeronýmova 10, 371 15 České Budějovice
[email protected]
Abstrakt: Polemizovat o tvrzení, že dnešní generace žáků základní školy je
internetová generace, je asi zbytečné. Článek si klade za cíl popsat, jak ve
skutečnosti používají děti internet, které jeho části preferují a které naopak málo
používají. Tato zjištění lze porovnávat s návyky učitelů. Autor vychází
z rozsáhlého průzkumu uskutečněného mezi více jak 630 žáky a 150 učiteli
z různých škol na území České republiky. Článek by mohl být inspirací pro tvůrce
školních webových stránek a pedagogy škol, jimž může doporučit vhodné
komunikační kanály směrem k žákům.
Klíčová slova: internet a žáci, školní webová stránka, internet, Facebook
Title: How Czech Students and Teachers use the Internet
Abstract: It is useless to argue about statement that contemporary generation
of students of elementary schools is the Internet generation. The aim of the article
is to describe how children use the Internet, which parts of the Internet they use
more and less. We can compare this finding out with the habits of teachers. The
author made a survey among 630 students and 150 teachers from different schools
in the Czech Republic. The article should be an inspiration for school web masters
and for teachers. It can recommend them appropriate communication channels to
students.
Keywords: Internet and students, School web site, Internet, Facebook
71
1 ÚVOD
Je třeba si uvědomit, že vzdělávání pouze ve školní budově je již překonaná záležitost. Rozvoj
Internetu a možnost ovlivňovat vzdělávání dětí nejen v době přímého vyučování, ale i v dalších
7 hodinách, které dítě aktivně tráví každý den mimo školní budovu, je šancí, kterou dnešní škola musí
využít. Metod, jak přinést vzdělávací obsah k dětem domů a jak je ovlivňovat a hlavně motivovat ke
vzdělání, je mnoho. Jednou z nich je zcela jednoznačná možnost použít Internet a speciálně školní
webovou stránku. Článek si klade za cíl popsat, jak ve skutečnosti používají děti internet, které jeho
části preferují a které naopak málo používají.
2 VYUŽITÍ INTERNETU V ČESKÉ REPUBLICE DLE
STATISTICKÝCH ZJIŠTĚNÍ
Na základě zjištění Českého statistického úřadu a Eurostatu mělo v domácnostech s dětmi přístup
k Internetu v roce 2010 na území České republiky cca 80%. Pro porovnání v roce 2005 to bylo pouze
32 %. V následující tabulce, která je převzatá ze Statistické ročenky ČSÚ 2010 [2] je patrno jejich
další rozdělení. Vyplývá z něj, že není platná rovnice - čím nižší vzdělání rodičů, tím menší šance na
využití Internetu doma. Největší podíl mají rodiny s úplným středním vzděláním. Každopádně 84 %
domácností je zcela zásadní počet a školy by měly tento fakt využít.
Tab. 1. Děti používající Internet doma. [2]
V článku Mladí a využití internetu ve Švédsku v roce 2009 [1] je uveden graf, ve kterém se ukazuje
změna zájmu o práci s Internetem v závislosti na věku dětí. Je z něj jasně patrno, že již nástupem do
školy ve věku 6, 7 let děti upouštějí od hraní her a sledování videí a postupně přibývá jiných činností
jako je instant messaging, vzdělávací činnosti a sociální sítě.
72
Nádvorník
Obr. 1. Co používají děti ve Švédsku na Internetu. [1]
Asi nejhorší je snažit se dnešní generaci vnutit způsob komunikace nás učitelů, kteří ale vyrůstali ve
zcela jiné době. Na toto zajisté naráží například učitelé českého jazyka, kteří řeší povinnou četbu. Není
možné ani v nejmenším zpochybňovat význam čtení a knih pro žáky. Ale kdo z češtinářů běžně
doporučuje Kindle, tablety, a nebo jiné čtečky e-booků? Autorův spolupracovník na škole zavádí jako
paralelní povinnou četbu poslech audioknih. Není náhodou toto přiblížení se k žákovým návykům
cesta, jak přiblížit literaturu dětem?
Tento příklad autor uvedl, protože i ve využití Internetu jsme my, učitelé, ve věku 40 let, již jiná
internetová generace. Dnešní děti se s Internetem seznamují již v předškolním věku, zatímco pro
průměrného čtyřicetiletého učitele byl Internet maximálně novinkou ke konci studia na vysoké škole,
ale spíše se s ním jako s nástrojem vzdělávání z pozice žáka nesetkal. A co teprve generace alfa,
kterou Papáček ve své práci Badatelsky orientované přírodovědné vyučování – cesta pro biologické
vzdělávání generací Y, Z a alfa [3] definuje takto: „Jako generace alfa bude zřejmě pojmenována
generace dětí rodících se v roce 2010 a v létech následných (pravděpodobně 2010–2024). První děti
z této generace se v prvních třídách základních škol objeví za 5 až 6 let. Futurologové mj. odhadují, že
tato generace bude výrazně vázaná na nové technologie, na virtuální elektronické prostředí
a počítačové modely pro potřeby rozhodování a sedavá zaměstnání." Jako učitelé máme dvě základní
možnosti. Přizpůsobit se dnešní a budoucí generaci a tím změnit naše návyky, anebo tuto nově
nastupující generaci změnit. Z po staletí známého generačního problému není druhá varianta možná.
3 JAK ČEŠTÍ ŽÁCI A UČITELÉ VYUŽÍVAJÍ INTERNET
V části autorova výzkumu uskutečněného v roce 2012 na reprezentativním vzorku 674 žáků a 150
učitelů z různých druhů škol z celé České republiky se autor zabýval využíváním Internetu. Z tohoto
výzkumu jsou vybrány dvě jeho části: Jaké činnosti se věnují na Internetu žáci a učitelé českých škol
a Jak vnímají otázku Facebooku. Průzkum byl uskutečněn prostřednictvím elektronického dotazníku
73
s uzavřenými i otevřenými otázkami. Respondenti byly získávání oslovením vybraných škol a pomocí
facebookové kampaně.
Obě pohlaví byla v souboru zastoupena přibližně rovnoměrně. Věková struktura souboru odpovídá
Gaussovu rozložení s tím, že věkové období 13-16 let je zastoupeno celkem 67%. Většina respondentů
(66%) navštěvuje základní školu. Rozložení respondentů ohledně místa návštěvy školy je rovnoměrné
přibližně podle rozložení obyvatelstva ČR. Z malých měst, vesnic a okresních měst je 55%
respondentů, krajská města jsou zastoupena 25% a Praha 18%. Toto rozdělení je pro účely mého
výzkumu plně reprezentativní.
Reprezentativnost vzorku je dále potvrzena na základě porovnání přístupu žáků k síti internet
z domova, kdy 75% respondentů průzkumu uvedlo, že mají k internetu přístup denně, což odpovídá
i šetření Českého statistického úřadu, kde 74% dětí má doma přístup k Internetu. [2]
V následující tabulce naleznete četnost využívání jednotlivých možností Internetu respondenty mého
výzkumu. Jsou zde uvedeny odpovědi na stejné otázky žáky a učiteli. Otázka zněla: Ohodnoťte, jak
často na Internetu se věnujete jaké činnosti.
Ohodnoťte, jak často na Internetu se věnujete jaké činnosti
Žáci
Činnost na Internetu
Učitelé
Velmi
často
Často
Téměř
nikdy
Velmi
často
Často
Téměř
nikdy
Čtení zajímavých informací
(časopisy, blogy, aj.)
40 %
61 %
38 %
46 %
69 %
25 %
Hledání obrázků a jiných
materiálů
64 %
79 %
20 %
xxx
xxx
xxx
Hraní on-line her
36 %
47 %
52 %
5%
7%
87 %
Chatování
71 %
78 %
21 %
9%
14 %
78 %
Komunikace prostřednictvím
SKYPE, ICQ, MSN,
případně jiné
57 %
67 %
32 %
21 %
29 %
66 %
Mailování
34 %
57 %
42 %
77 %
79 %
16 %
33 %
48 %
81 %
46 %
80 %
16 %
40 %
52 %
47 %
5%
9%
83 %
Prohlížení sítě Facebook
74 %
80 %
19 %
15 %
19 %
75 %
Prohlížení videí na portálech
Youtube, Stream, případně
jiných
76 %
86 %
13 %
22 %
46 %
48 %
Navštěvování webových
stránek své školy
Používání jiných sociálních
sítí
74
Nádvorník
Přispívání do diskusních fór
36 %
48 %
51 %
4%
10 %
82 %
Stahování filmů, hudby, her
58 %
74 %
25 %
9%
16 %
78 %
Vyhledávání informací
potřebných pro referáty
(učitelé výuku)
28 %
60 %
39 %
64 %
84 %
11 %
Tab. 2. Činnosti žáků a učitelů na Internetu.
V tabulce jsou uvedeny kumulativní odpovědi, kdy „Často“ denně, několikrát týdně a jednou týdně
z toho „Velmi často“ znamená denně, případně několikrát týdně, a „Téměř nikdy“ znamená odpovědi
méně často a nikdy.
Nejčastější činností žáků bylo prohlížení videí, kde více jak tři čtvrtiny z nich se této činnosti věnují
velmi často. (Toto autorovo zjištění je v rozporu se švédským výzkumem a ukazuje na možnou
specifičnost českých dětí.) Zde je z pohledu školní webové stránky veliká šance na použití vhodné
multimediální technologie pro přiblížení se zvyklostem žáků. Tuto preferenci potvrzují i žáci autorovy
školy, kteří v rámci orientačního rozhovoru s autorem velmi oceňovali výuková videa na serveru
Youtube, která jsou speciálně pro ně vytvářena. Počet zhlédnutí výukových videí autora článku
mnohdy přesahuje 3000, a to se v žádném případě nejedná jenom o žáky jeho školy, ale i o náhodné
návštěvníky, kteří tato videa objevili prostřednictvím vyhledávače. Výuková matematická a fyzikální
videa je možné zhlédnout na kanále youtube.com/adlif57. Videa zde publikovaná jsou podobná videím
americké Kahn Academy a její využití metody Fliped Classroom.
Další logicky častou činností žáků je práce na síti Facebook. Velmi časté využití Facebooku u 74 %
žáků je poměrně vysoký podíl. Z pohledu školní webové stránky je však toto číslo obtížně použitelné,
neboť v jiné části tohoto výzkumu žáci zcela jednoznačně odmítli využití oficiální školní Facebookové
prezentace.
Další výraznou činností žáků je chatování, které ale často souvisí s používáním sítě Facebook.
Zajímavou položkou je 61 % žáků, kteří často využívají Internet pro vyhledávání informací ke
školním pracem a referátům. Této činnosti se převážně věnují 1 x týdně, což může ukazovat i na menší
množství domácích zadání, při nichž je třeba využívat Internet. Učitelé by poté ale měli dbát na
pravidla citací z Internetu a využívat portály hlídající shodu v dokumentech. Například server
www.odevzdej.cz je možné používat i pro kontrolu shod seminárních prací. Jednodušší variantou je
využití vyhledávače Google, kde stačí zadat první frázi a mnohdy se objeví doslovná kopie. Nemluvě
o té skutečnosti, že nejčastějším zdrojem žákovských prací je Wikipedia.
Další častou činností žáků je stahování multimediálního obsahu. Zde je otázkou, jestli se jedná
o legální činnost, ale dle zkušeností autora a rozhovorů s žáky se častěji jedná o porušování autorského
zákona. V tomto ohledu je třeba šířit větší osvětu mezi žáky.
Z méně častých odpovědí je nejvíce zarážející řídké používání e-mailu žáky, což je pro velké množství
učitelů denní činností. Žáci se této činnosti věnují mnohem méně, až téměř nevěnují.
75
Učitelé naproti tomu nejvíce na internetu preferují čtení časopisů, používání emailu a navštěvování
stránek své školy. Poměrně povzbudivou skutečností je 84% učitelů vyhledávající zdroje informací
pro svoji výuku na Internetu. Toto je však v rozporu s mojí zkušeností lektora v rámci dalšího
vzdělávání pedagogických pracovníků, kdy se toto procento ukazovalo nižší.
4 FACEBOOK A JEHO VYUŽITÍ ŽÁKY A UČITELI
Fenomén sítě Facebook je v dnešní době zásadně patrný. 570 žákovských respondentů z 638 uvedlo,
že profil na síti Facebook mají, z nich 423 profil udržují aktuální. Zajímavé je, že i 82 žáků ve věku 11
a 12 let uvedlo, že profil na síti Facebook má. Toto se děje i přes přísná pravidla sítě Facebook, která
omezují věk uživatelů na více jak 13 let (jež se dají snadno obejít uvedením nepravého roku narození).
Na základě rozhovorů s žáky 6. ročníku autorovy školy (nebyly součástí výzkumného vzorku) o tom
zákonní zástupci ve většině případů vědí a akceptují to. Dále z rozhovorů vyplynulo, že profil na
Facebooku je pro žáky téměř nezbytný, neboť by se jinak dostali mimo hlavní sociální směr
a komunitu. Na druhou stranu pouze 30 % učitelů má profil na síti Facebook a jen 13 % jej pravidelně
udržuje.
Je ovšem otázkou, jak tuto síť využít pro účely školní webové prezentace. Zde se naráží na zcela
zásadní etický problém, zvláště na základních školách a na víceletých gymnáziích. Škola nemůže
provozovat stránku, na které toleruje porušování pravidel. Proto by Facebookový profil základní školy
mohl být určen pouze starším žákům, absolventům a rodičům. Jak by ale v takovém případě šlo
zabránit vstupu žákům mladším?
Pouze 15 % žáků uvedlo, že škola má oficiální stránku na síti Facebook. V tomto výčtu zcela zásadně
převažovaly střední školy. Na základě těchto dat lze konstatovat, že školy využívají Facebook
minimálně.
Na druhou stranu facebookové skupiny, které se vztahují k jednotlivým školám, jsou na Internetu
poměrně rozšířené. 51 % respondentů uvedlo, že o nějaké takovéto skupině ví. Předpokládám tedy, že
toto je cesta, jak se žáci sdružují na síti Facebook a jedná se tedy v podstatě o neoficiální stránky škol
na Facebooku. Na příkladu autorovy školy je možné ukázat, že takovýchto skupin je celkem 9. Většina
skupin je otevřených, největší z nich má 285 členů. Samotná aktivita v těchto skupinách je ale velmi
malá. Existují ale i uzavřené třídní skupiny, které slouží pro sdílení poznámek ze školy, zadání
domácích úkolů a dalších školních informací. Toto však probíhá zcela mimo oficiální kontrolu školy.
Klíčovou otázkou ohledně využití Facebooku pro školní webovou prezentaci byla otevřená otázka,
„Co si myslím o možném využití Facebooku pro školní webovou stránku?" Objevilo se zde mnoho
odpovědí, které jsem pro účely zpracování upravil kódováním na tři základní vztahy pozitivní
negativní a neutrální.
76
Nádvorník
Co si myslím o možném využití Facebooku na školní webové stránce
Agregovaná
odpověď
Žáci
Učitelé
Počet
odpovědí
Procent z
celku
Procent z
odpovědí
Počet
odpovědí
Procent z
celku
Procent z
odpovědí
Pozitivní
98
15 %
27 %
19
13 %
23 %
Neutrální
152
23 %
41 %
19
13 %
23 %
Negativní
117
18 %
32 %
44
30 %
54 %
Bez odpovědi
271
44 %
–
68
44 %
–
Tabulka 3. Využití Facebooku na školní webové stránce.
Pozitivní přístup ke školnímu Facebooku má pouze cca 15 % (žáci) resp. 13 % (učitelé) respondentů.
Nejsilněji je v této skupině u žáků zastoupen věk 16 let, 21% šestníctiletých respondentů se staví
k Facebooku pozitivně. Ostatní věkové skupiny jsou přibližně vyrovnané. Nejpopulárnější je školní
Facebook v Praze, kde se 22 % staví k němu pozitivně. Vysoký informační potenciál Facebooku
ukazuje i skupina respondentů, která nejvíce na webových stránkách školy vyhledává informace
o akcích třídy nebo školy. Z nich více jak 25% se na Facebook a jeho použití ve školním webu dívá
pozitivně. Dále se podpora Facebooku zvyšuje v souvislosti s četností návštěv webové stránky školy.
35 % žáků, kteří uvedli, že školní webovou stránku navštěvují několikrát týdně, podporují také školní
Facebook.
Je třeba se zamyslet nad obecně velmi malou podporou školního Facebooku. Příčiny, proč žáci
nepodporují školní facebookové profily, lze najít v otevřených odpovědích. Z nich z velké části
vyplynulo, že žáci považují Facebook za své soukromí a nepřejí si, aby školy do něj vstupovaly. Dále
mnohdy nechápou, jak konkrétně by školní Facebook mohl zlepšit jejich komunikaci se školou.
Využití Facebooku pro školní účely hodnotí zásadně negativně i žáci škol, které facebookovou stránku
provozují. Například na Biskupském gymnáziu a základní škole Bohosudov, kde Facebookový profil
funguje, pouze 13 % respondentů pozitivně hodnotí Facebook a 27 % jej hodnotí negativně. Toto
může být dáno i nepravidelnou aktualizací školního profilu. Z pohledu učitelů využití Facebooku často
naráží na určité předsudky, kdy učitelé často neví, co přesně Facebook je a jaké jsou jeho možnosti
využití. Mnoho učitelů se na Facebook dívá spíše z pohledu rodiče, kde jeho dítě "stále sedí na
Facebooku" a vnímá jej i jako určité bezpečnostní riziko.
Škola by tedy měla uvažovat, zda a proč případnou Facebookovou stránku tvořit a udržovat. Jak jsme
již ukázali, žáci považují zřízení a správu oficiálního školního profilu na síti Facebook za neefektivní.
Profil by tedy mohl být adresován na zákonné zástupce budoucích žáků, či jako komunitní server pro
absolventy. Takové stránky však vznikají spontánně a školy do nich příliš nezasahují.
Popisovaný stav vychází z roku 2012. Je otázkou, jakým způsobem se bude vyvíjet vztah učitelů
a žáků k Facebooku a co by škola měla a mohla udělat pro zlepšení své internetové komunikace
s žáky. Vycházíme z předpokladu, že předložení maxima informací žákům jim může ulehčit cestu ke
77
vzdělání. Samozřejmě by měly existovat situace, kdysi sami žáci najdou potřebné zdroje, ale pak je na
učiteli, aby ohodnotil relevanci a šíři zdrojů.
5 UŽITEČNÉ TIPY PŘI PROVOZU ŠKOLNÍ WEBOVÉ STRÁNKY
Na základě výše uvedených skutečností a dalších zjištění z mého a jiných průzkumů [4] a [5] se dají
formulovat určitá obecná doporučení týkající se efektivního provozu školní webové stránky.

Udržovat školní webovou stránku aktuální, moderní a přístupnou pro žáky.

Zveřejňovat maximum možných informací potřebných pro žáky na školních webových
stránkách. V případě, že toto stávající školní webová stránka neumožňuje, je možné použít
některá z otevřených řešení. Například blogovací systémy sites.google.com, bloguj.cz,
webnode.cz aj. Další zajímavou možností je grafická nástěnka. Žáci musí nabýt přesvědčení,
že jim návštěva stránky ušetří čas a pomůže důležité věci udržet v paměti.

Používat cloudové nebo e-learningové řešení zadávání a odevzdávání úloh.

Využívat a žákům přímo předkládat elektronické studijní materiály.

Vytvářet pro žáky autentické výukové materiály a ty publikovat na stránkách. (Příkladem je
nahrávání výkladových hodin na video, vytváření online testů, vytváření elektronické časové
osy, atd.)

Zkusit využít diskusní fórum pro dlouhodobější diskusi žáků na zadané téma.

Konzultační hodiny je možné držet pomocí SKYPE, žáci i rodiče budou vědět v jakém čase
jim je učitel na svém kanále k dispozici. Toto řešení se v autorově případě poměrně hodně
osvědčilo. Rodiče mnohdy nemají čas na návštěvu školy, ale na SKYPE rozhovor si čas
udělají.

Facebooková stránka jako komunikační kanál školy je diskutabilní a závisí na místní situaci.

Omezit emailovou komunikaci s žáky - žáci email mnohdy nekontrolují a nevyužívají.
6 ZÁVĚR
Většina obyvatel České republiky Internet zcela běžně používá. Je však zřejmé, že způsob jeho využití
se liší v závislosti na věku uživatelů. V případě školy je možnost využít školní webovou stránku jako
komunikační nástroj s žáky možností efektivní. Narážíme zde však více než jindy na zásadní generační
rozdíl. V praxi jsou k dispozici dva přístupy. V prvním případě budou učitelé nutit žáky komunikovat
a používat internet způsobem čtyřicetiletého člověka, který používá email, minimálně diskutuje
a komentuje příspěvky, multimédia příliš nevyhledává a Facebook či jiné sociální sítě odmítá. Druhý
přístup je snažit se přizpůsobit komunikačním návykům žáka a více publikovat multimediální
záznamy, otevřít příspěvky k diskuzi, omezit emaily případně začít komunikovat pomocí IM klientů
78
Nádvorník
v reálném čase. I zde se jeví jako ideální řešení určitá střední cesta, kdy své styly práce s internetem
přizpůsobí jak učitelé, tak i jejich žáci.
[1]
FINDHALD O. The young and the Internet in Sweden, The World Internet Institution.
[online]. Sweden: World Internet Institute, 2009 [cit. 2013-04-12]. Dostupné z
http://worldinternetproject.com/_files/_Published/48/The%20young%20and%20the%20Intern
et%20in%20Sweden%202009.pdf
[2]
Jednotlivci používající Internet doma. In Statistická ročenka České republiky 2010 :
Informační a komunikační technologie [online]. Praha : Český statistický úřad, 2011 [cit.
2013-05-14]. Dostupné z: http://www.czso.cz/csu/2010edicniplan.nsf/kapitola/0001-10--2000.
[3]
PAPÁČEK, M. Badatelsky orientované přírodovědné vyučování – cesta pro biologické
vzdělávání generací Y, Z a alfa?. Scientia in educatione. 2010, 1, s. 33-49. ISSN 1804-7106.
[4]
NEUMAJER, O. Náležitosti školního webu. 2007, 2011 [cit. 2013-04-12] Dostupné z:
http://ondrej.neumajer.cz/download/nalezitosti-skolniho-webu.pdf.
[5]
NEUMAJER, O. Webové stránky škol v roce 2009. [cit. 2013-04-12] Porál Ředitel školy.cz.
12. 10. 2009. Dostupné z: http://www.reditelskoly.cz/show.asp?id=808.
2(1), 2013, 79–90, DOI: 10.18267/j.aip.15
Online: aip.vse.cz
Sekce / Section:
Viacjadrová architektúra zameraná
na akceleráciu výpočtov
Liberios Vokorokos1, Eva Chovancová1
1
Katedra počítačov a informatiky, Fakulta elektrotechniky a informatiky
{liberios.vokorokos, eva.chovancova}@tuke.sk
Abstrakt: Viacjadrové procesory je možné navrhnúť ako akcelerátor
časovo-náročných výpočtov. Výskum v práci je zameraný na návrh architektúry
urýchľujúcej výpočty v oblasti počítačového videnia. Práca poukazuje na možnosti
návrhu viacjadrovej architektúry, pričom architektúra navrhovaného
špecializovaného procesora je predstaviteľom Harvardskej architektúry. Navrhnutá
architektúra umožňuje na základe paralelizácie výpočtov urýchliť časovo-náročné
výpočty.
Klíčová slova: viacjadrová architektúra, prahovanie, obraz, procesor, čip,
mapovanie, paralelizácia
Title: Acceleration based on multicore architecture
Abstract: Multicore processors can be designed also as accelerator of
time-consuming calculations. This work is focused on architecture design, which
can accelerate computing in computer vision. In this paper are shown design
possibilities for multicore architectures, whereby the specialized processor is
proposed as representative of Harvard architecture. The proposed architecture
based on computing parallelization allows accelerating the time-consuming
calculations in computer vision.
Keywords: multicore architecture, thresholding, image, processor, chip, mapping,
parallelization
80
Vokorokos, Chovancová
1 ÚVOD
Výpočtová technika a informačne systémy sa stali neodmysliteľnou súčasťou každodenného života, či
už v oblasti výskumu, kde je potrebný vyšší výkon z dôvodu náročných výpočtov, alebo aj bežného
života v domácnosti. V dnešnej dobe je správa informácii s ich narastajúcim množstvom stále
zložitejšia, potreby vedeckého výskumu s vývojom nových technológii stále narastajú, a preto je stále
aktuálna požiadavka na zvyšovanie výkonu výpočtových systémov.
Zvyšovanie výkonov u jedno procesorových počítačov, ktoré sú vo väčšine predstaviteľmi von
Neumanovej architektúry, sa realizuje zvyšovaním výkonu jednotlivých komponentov počítača,
pričom je potrebné zároveň zväčšovanie pamäte. Tento spôsob zvyšovania výkonu ma však za
dôsledok zvyšovanie nákladov na vývoj jednotlivých komponentov, a zároveň táto metóda má aj svoje
fyzikálne hranice. Trend zvyšovania rýchlosti jednotlivých komponentov procesorov za účelom
získania vyššieho výkonu je cestou minulosti, nakoľko sa viacjadrové procesory stávajú novým
smerovaním vývoja. Použitie viacjadrových procesorov na jednom čipe je výhodou hrubej sily
spracovania, avšak nič nie je zadarmo. [2][3][10]
Práca sa zaoberá analýzou problematiky viacjadrových architektúr, na základe ktorej navrhuje
architektúru špecializovaného viacjadrového procesora pre akceleráciu výpočtov v oblasti
počítačového videnia. Táto práca bola podporovaná Agentúrou na podporu výskumu a vývoja na
základe zmluvy č. APVV-0008-10 a KEGA 008TUKE-4/2013 s názvom „Mikrolearningové
prostredie pre vzdelávanie odborníkov v oblasti informačnej bezpečnosti“.
2 KONCEPCIE
Pri návrhu špecializovanej architektúry je dôležitá aj voľba koncepcie. Základné koncepcie, ktoré sa
brali do úvahy pri návrhu architektúry sú:


Harvardská koncepcia
Princetonská koncepcia
Princetonská koncepcia má len jednu spoločnú pamäť pre dáta a inštrukcie. Harvardská koncepcia na
rozdiel od princetonskej obsahuje dve samostatné pamäte pre dáta a inštrukcie.
2.1 HARVARDSKÁ KONCEPCIA
Harvardská koncepcia je počítačová architektúra s fyzicky separovaným úložným priestorom
a signálovou cestou pre inštrukcie a údaje, čo znamená že ma oddelený adresný priestor pre program
a pre dáta. Dnes väčšina procesorov ma implementovanú separátnu signálovú cestu z dôvodu výkonu,
ale v spojení s modifikovanou harvardskou architektúrou, ktorá umožňuje podporiť úlohy ako
zavádzanie programu z disku vo forme dát a následne ho vykonať. V harvardskej architektúre nie je
potrebné, aby pamäte zdieľali vlastnosti, keďže časovanie, technológia implementácie a adresná
štruktúra pamäte sa môžu líšiť. [4]
81
V niektorých systémoch môžu byť inštrukcie uložene v pamäti len na čítanie, keďže pamäťové údaje
požadujú pamäť na čítanie a aj zápis. V niektorých systémoch je pamäť pre inštrukcie väčšia ako
pamäť pre dáta, keďže adresa inštrukcie je širšia ako adresa dát.[3][4]
2.2 PRINCETONSKÁ KONCEPCIA
Jedným z najznámejších predstaviteľov Princetonskej koncepcie je von Neumanova architektúra, ktorá
je jednoduchšia ako novšia Harvardská architektúra. Von Neumanova architektúra na rozdiel od
Harvardskej obsahuje len jednu pamäť, ktorá slúži pre ukladanie dát a aj inštrukcii, čo znamená že
obsahuje jeden spoločný súbor adries pre dáta a inštrukcie.
Z toho vyplýva, že je potrebne zabezpečiť, aby procesor neinterpretoval údaj ako inštrukciu a naopak.
Prístup procesora k pamäti je totiž rovnaký, či sprístupňuje inštrukciu alebo údaj – používajú sa tie iste
adresné, údajové i riadiace signály. Takéto usporiadanie pamäte potom umožňuje používať aj samo
modifikujúce sa programy. [3][4]
Von Neumanova architektúra je systém s možnosťou uloženia programu do operačnej pamäte, pričom
inštrukcie a dáta sú uložene v pamäti typu RAM, ktorá je určená pre čítanie a zápis. Vo Neumanovej
architektúre CPU môže buď čítať inštrukcie alebo čítať/zapisovať dáta z alebo do pamäte. Obidve
operácie sa nemôžu vykonať súbežne, keďže dáta a inštrukcie využívajú spoločnú pamäť.
V Harvardskej architektúre sa môže pracovať súbežne s inštrukciami a dátami, keďže majú samostatne
pamäte. Z uvedeného dôvodu je Harvardská architektúra rýchlejšia. [4]
3 VIACJADROVÁ ARCHITEKTÚRA
Vysoko výkonné procesorové architektúry smerujú k prevedeniu, ktoré sú reprezentované viacerými
procesorovými jadrami na jednom čipe. Tieto architektúry majú potenciál poskytnúť vyššiu
maximálnu priepustnosť, jednoduchší návrh škálovatelnosti a vyšší výkon než monolitické
architektúry. Súčasným trendom vývoja technológií sú aj nové typy procesorov, ktoré by mali pokryť
potrebu vyššieho výkonu bez zvýšenia spotreby energie a tepla. Viacjadrové architektúry procesorov
umožňujú zvýšenie výkonu a zníženie tepla integráciou dvoch alebo viacerých procesorových jadier
v jednom procesorovom puzdre.[12]
Stretávame sa s procesormi, ktoré majú integrované veľké množstvo jadier. Pri týchto procesoroch je
najlogickejšie usporiadanie v dimenzionálnej mriežke, a preto sú využívané control flow, ako aj dáta
flow architektúry jadier. Na základe definície procesora v predchádzajúcej kapitole, vieme viacjadrový
procesor popísať ako integrovaný obvod, na ktorý sú pripojené dva alebo viaceré procesory, ktoré sa
nazývajú aj jadrá. Takýmto zapojením je možné zvýšiť výkon, znížiť spotrebu energie a efektívnejšie
simultánne spracovanie úloh, čo prinieslo rastúci trend v oblasti viacjadrových procesorov, keďže
jednojadrové procesory dosiahli svoje limity z hľadiska výkonu a rýchlosti. [12][13]
82
4 NÁVRH ŠPECIALIZOVANEJ ARCHITEKTÚRY
Návrh architektúry špecializovaného procesora vychádza z analýzy v oblasti viacjadrových procesorov
a počítačového videnia. Vzhľadom na napredujúci vývoj viacjadrových procesorov a počítačové
videnie, v ktorom sa využívajú algoritmy umožňujúce ich paralelizáciu, je vhodné využiť viacjadrový
procesor práve na akceleráciu výpočtov v oblasti počítačového videnia. Aj keď je možné využiť
v oblasti počítačového videnia aj univerzálne viacjadrové procesory, tak špecializovaný viacjadrový
procesor umožňuje vyšší výkon a rýchlejšie spracovanie dát, vzhľadom na to, že jeho architektúra bola
navrhnutá práve na spracovanie algoritmov z tejto oblasti. [3]
4.1 MAPOVANIE OBRAZU
Navrhnutý špecializovaný procesor umožňuje niekoľko prístupov k mapovaniu obrazu, ktoré sa líšia
v rozdelení digitálneho obrazu, ale aj počtom využitých jadier.
Vstupný obraz
Procesor Covitor (4 x 4)
Obr. 1. Mapovanie obrazu o rozmere 256 x 256 pixelov.
Na obrázku (Obr. 1) je znázornené mapovanie digitálneho obrazu na jednotlivé jadrá procesora,
v prípade ak veľkosť digitálneho obrazu je 256 x 256 pixlov, čo je maximálna veľkosť spracovaného
obrazu. Pri tomto prístupe mapovania sa obraz rozdelí na rovnako veľké časti, ktoré zodpovedajú
presne veľkosti pamäte jedného jadra. Pokiaľ je obraz menší, tak je možné využiť dva spôsoby
prístupu mapovania obrazu. Prvý spôsob využíva všetky jadra, tým pádom sú všetky jadra rovnomerne
vyťažené, ale nevyužije celú pamäť jadra. [5]
Druhý spôsob, ktorý je možné využiť pri menšom obraze je nerovnomerný, avšak je využitá celá
pamäť jadra, avšak tento prístup mapovania nie je efektívny, keďže časovo spracováva ten istý obraz
dlhšie ako rovnomerný prístup. Ako bolo už vyššie uvedené, tak vstupný obraz môže mať maximálny
rozmer 256 x 256 pixelov, a síce z toho dôvodu, že k dispozícií máme 16 jadier s možnosťou využitia
kapacity pamäte o veľkosti 256bodov 256bodov 3bajty RGB
4banky 786432bajtov.
Obraz je ukladaný do samostatných pamäťových bánk, čo umožňuje načítať naraz 4 samostatné
obrazy a následne ich postupne spracovať.[10][11]
83
5 ŠPECIALIZOVANÝ PROCESOR COVITOR
Navrhnutý procesor Covitor je viacjadrový procesor so 16-timi jadrami, ktorý je špecializovaný na
spracovanie digitálneho obrazu na základe inštrukčnej sady popísanej v predchádzajúcej kapitole.
Navrhnutý procesor je predstaviteľom harvardskej architektúry, teda má samostatnú pamäť pre dáta
a samostatnú pamäť pre inštrukcie. Vzhľadom na dve pamäte je prístup k dátam a inštrukciám
rýchlejší, a taktiež sa zabráni chybnému načítaniu údajov.
Jadrá procesora Covitor sú usporiadané vo forme mriežky 4x4. Štruktúrna schéma procesora Covitor
je znázornená na nasledujúcom obrázku (Obr. 2). Všetky porty procesora Covitor sú popísané
pomocou tabuľky.
Obr. 2. 16-jadrový procesor Covitor.
Procesor operuje v dvoch módoch. Módy pmod a cmod slúžia na nastavenie systému do
programovacieho alebo výpočtového módu. V programovacom móde sa načítavajú vstupné hodnoty
do registrov/pamäte a časovanie systému. Potom sa prestaví systém do výpočtového módu, kedy sa
spustia výpočty na základe programu, ktorého súčasťou sú inštrukcie vykonávané nad jednotlivými
dátami.
84
Typ
Veľkosť
portu
(bit)
adr
In
12
Adresa pamäte
ac
In
4
Adresa jadra
ab
In
2
Adresa banky
tag
In
1
Príznak pre adresovú pamäť
sigr
In
1
Určuje kedy je povolené čítanie z registra/pamäte
sigw
In
1
Určuje kedy je povolený zápis do registra/pamäte
sigwrpp
In
1
Určuje kedy je povolený zápis do registra RPP
pmod
In
1
Zavádzací mód
cmod
In
1
Výpočtový mód
rst
In
1
Resetovanie (Reset)
clk
In
1
Hodiny (Clock)
clr
In
1
Vyčistenie (Clear)
done
Out
1
Ukončenie cyklu, aby sa mohol začať nový cyklus
data
InOut
24
Výstupné dáta po spracovaní obrazu
Port
Popis
Tab. 1. Popis portov procesora Covitor.
Done slúži na signalizáciu ukončenia cyklu spracovania údajov, ktoré sú umiestnené na konkrétnej
adrese v pamäti. Pokiaľ príde na port done hodnota jedna, tak cyklus bol ukončený a preto sa adresa
nastaví na ďalšiu adresu v pamäti a spustí sa ďalší cyklus výpočtov. Procesor Covitor obsahuje dva
nižšie uvedené komponenty, ktorých prepojenie je definované pomocou mapovania. Tieto
komponenty sú:


Jadro (Core)
Dekodér (Decoder)
Komponent Core predstavuje jedno univerzálne jadro procesora, ktoré je následne mapované na 16
jadier a komponent Decoder slúži na adresáciu jadier.
5.1 PROCESOROVÉ JADRO
Procesor Covitor je navrhnutý ako viacjadrový procesor so 16 jadrami, ktorého architektúra patrí
medzi predstaviteľov harvardskej architektúry. Predstaviteľom tejto architektúry je práve preto, že je
navrhnutý so samostatnou pamäťou pre inštrukcie a samostatnou pamäťou pre dáta. Pamäť pre
inštrukcie je umiestnená priamo v jadre, pričom pamäť pre dáta, ktorá je zároveň väčšia, je vnorená do
vykonávacej jednotky. Pri zapojení procesora prostredníctvom 16-tich jadier získame zvýšený výkon
potrebný pre rýchlejšie spracovanie obrazu. Čas potrebný na spracovanie obrazu vieme vyjadriť
prostredníctvom vzorcu:
85
(1)
V uvedenom vyjadrení m predstavuje počet pixelov, ktoré tvoria digitálny obraz pripravený na
spracovanie a n predstavuje počet jadier, ktoré ich spracujú. Zo vzorca vyplýva, že čím väčší počet
jadier použijeme tým nižší bude čas potrebný na spracovanie toho istého počtu pixelov. Schematické
zapojenie jedného jadra je znázornené na nasledujúcom obrázku (Obr. 3).
Jadro procesora Covitor pozostáva z pamäte, registra F, počítadla (program counter -PC), sčítačky,
riadiacej jednotky a vykonávacej jednotky, pričom vykonávacia jednotka zahrňuje v sebe
aritmeticko-logickú jednotku.
Register
Vykonávacia
jednotka
Pamäť
Program Counter
Sčítačka
Riadiaca jednotka
Obr. 3. Schematické zapojenie jadra.
Digitalizovaný vstupný obraz sa načíta do pamäte, ktorá je umiestnená vo vykonávacej jednotke
a program (inštrukcie) sa načítajú do pamäte umiestnenej v jadre. Spracovanie obrazu sa následne
vykonáva v štyroch fázach, ktoré sú riadené riadiacou jednotkou.
V prvej fáze sa načíta inštrukcia do registra F a následne v druhej fáze sa vyšle štartovací signál, ktorý
spustí spracovanie obrazu vo vykonávacej jednotke. V tretej fáze sa spustí vykonávacia jednotka,
v ktorej sa vykoná požadovaná inštrukcia nad vstupným obrazom. V poslednej, štvrtej, fáze sa vyšle
ukončovací signál, ktorý ukončí vykonávanie inštrukcie nad daným vstupným obrazom.
5.1.1
RIADIACA JEDNOTKA
Riadiaca jednotka pracuje na princípe konečného automatu ktorý pozostáva zo štyroch stavov
popisujúcich spracovanie obrazu. Prechod medzi jednotlivými stavmi je zabezpečený riadiacou
86
logikou, ktorá berie do úvahy signál riadiacej jednotky a podmienky, ktoré musia byť splnené, aby sa
prechody mohli uskutočniť.
Aby nastal prechod medzi stavmi, musí sa automat nachádzať v predchádzajúcom stave a zároveň
musí byť nastavený programovací mód. Pre spustenie spracovania obrazu, ktorý zodpovedá stavu S3,
musí ešte okrem uvedených podmienok prísť na vstup aj štartovací signál. Pri prechode do stavu S4 je
potrebné, aby prišiel na vstup signál done, ktorý hovorí o ukončení spracovania obrazu.
5.1.2
VYKONÁVACIA JEDNOTKA
Vykonávacia jednotka je modul, ktorý je súčasťou jadra procesora a jej hlavnou úlohou je vykonanie
inštrukcie nad vstupnými údajmi, ktoré má načítané vo svojej vnútornej pamäti. Zároveň obsahuje aj
čiastkový logický obvod, ktorý umožňuje kontrolovať ukončenie spracovania obrazu. Vykonávacia
jednotka je realizovaná na základe logického obvodu uvedeného na obrázku (Obr.4).
Vykonávacia jednotka je zodpovedná za spracovanie obrazu prostredníctvom prahovania, prípadne
prevodu digitálneho obrazu z RGB do odtieňov sivej. Spustenie spracovania obrazu je riadenie
štartovacím signálom, ktorý signalizuje začiatok spracovania.
Vstup
Prevod RGB ->
sivá
Pamäť Register R8 Vstup
Prahovanie
Vstup
Modul adresácie Vstup
Aritmeticko-logická jednotka
Obr. 4. Schematické zapojenie vykonávacej jednotky.
Výsledok spracovania digitálneho obrazu sa uloží do výstupného registra R8, do ktorého sa ukladajú
výsledky pri prahovaní a aj pri prevode do odtieňov sivej. Pre zabezpečenie správnosti zapísania
údajov do registra R8, bol vytvorený súbor pravidiel, ktorý určuje, kedy a ktoré výsledky sa majú
zapísať do registra R8. Dôležitou súčasťou vykonávacej jednotky je modul adresácie, ktorý má za
87
úlohu určiť adresu čítania údajov a zároveň po spracovaní údajov z poslednej adresy ukončí
spracovanie.
5.1.3
VYKONÁVACIA JEDNOTKA
Súčasťou vykonávacej jednotky je aj aritmeticko-logická jednotka, ktorá zodpovedá za vykonanie
jednotlivých inštrukcií nad požadovanými údajmi, pričom výstup jednotlivých operácií sa ukladá do
výstupného registra R8. Taktiež súčasťou aritmeticko-logickej jednotky je aj dekodér, ktorý slúži na
dekódovanie požadovanej inštrukcie, na základe ktorej sa určí, aká operácia sa nad danými údajmi má
vykonať. Ďalšou súčasťou aritmeticko-logickej jednotky sú riadiace signály, ktoré majú za úlohu
odštartovanie jednotlivých inštrukcií. Tieto inštrukcie sa vykonávajú na základe dekódovania
inštrukcie.
Aritmeticko-logická jednotka sa dá rozdeliť na dva čiastkové logické obvody, pričom jeden má za
úlohu prevod vstupného digitálneho obrazu vo formáte RGB do formátu odtieňov sivej. Druhý
čiastkový logický obvod zodpovedá za spracovanie obrazu prostredníctvom jednotlivých typov
prahovania obrazu.
6 SIMULÁCIA
Jednou možnosťou ako urýchliť spracovanie obrazu je použitie viacerých jadier na jednom čipe,
pričom sa rozloží záťaž na viacero jadier a každé jadro musí spracovať menší počet pixelov. Pri
spracovaní obrazu rôznym počtom jadier za ten istý čas spracuje procesor s väčším počtom jadier
viacnásobne väčší počet pixelov (Obr. 5).
1000
Počet pixelov
875
750
625
500
375
250
125
0
0
500
1000
1500
2000
2500
3000
Čas t [SC]
1 jadro
4 jadrá
16 jadier
Obr. 5. Spracovanie obrazu rôznym počtom jadier.
3500
4000
88
Ako z uvedeného grafu vyplýva, tak pri spracovaní obrazu s rovnakým počtom pixelov, procesor so
16 jadrami na jednom čipe spracuje daný obraz za 16x menší počet strojových cyklov (SC). Pri
simulácii spracovania digitálneho obrazu pomocou špecializovaného procesora pozostávajúceho zo 16
jadier na jednom čipe sa použil obraz v rozlíšení 256x256, preto celkový počet pixelov určených na
spracovanie obrazu je:
početpixelov
256 x 256
65536
(2)
Pri testovaní uvažujeme o rovnomernom zaťažení jadier a preto pri počte pixelov 65536 na každé
jadro pripadne 4096 pixelov. Každý pixel obsahuje informácie o zastúpení červenej (R), zelenej (G)
a modrej (B) zložky, pričom v kombinácii predstavujú konkrétny odtieň farby. Jednotlivé informácie
o pixeloch sú importované na spracovanie zo súboru, kde sú uložené ako hrubé dáta v poli
zodpovedajúce jednotlivým zložkám R-G-B.
Pri spracovaní obrazu v menšom rozlíšení, sa pri rovnomernom rozložení záťaže procesorom Covitor
využijú všetky jadra, pričom každé spracováva rovnaký počet pixelov. Pri nerovnomernej záťaži sa
využije len niekoľko jadier, medzi ktoré sa rozdelí záťaž a zvyšné jadrá nevykonávajú žiadnu činnosť.
Z hľadiska efektivity je vhodnejšie použiť rovnomerné rozdelenie záťaže, keďže je potrebný nižší čas
na spracovanie obrazu ako pri nerovnomernej záťaži jadier. Navrhnutý špecializovaný procesor
Covitor obsahuje základnú inštrukčnú sadu, ktorú je možné do budúcna rozšíriť o ďalšie inštrukcie
pre spracovanie obrazu.
7 PRÍNOSY ŠPECIALIZOVANEJ ARCHITEKTÚRY
Prínosy práce je možné hodnotiť z teoretického a praktického hľadiska. Teoretické prínosy prispievajú
hlavne k vývoju problematiky viacjadrových procesorov a ich návrhu. Praktické prínosy práce
predstavuje návrh a simulácia špecializovanej architektúry pre akceleráciu výpočtov v počítačovom
videní. Prínosy práce je možné zhodnotiť v nasledujúcich bodoch:




Preskúmanie výhod a nevýhod využitia harvardskej a princetonskej architektúry.
- Uvedený prínos patrí medzi teoretické prínosy práce, pričom na jeho základe sa
preukázalo, že pre návrh procesora Covitor je vhodnejšia Harvardská architektúra
z dôvodu rýchlejšie prístupu k dátam a inštrukciám.
Samostatný návrh špecializovanej architektúry so zameraním na akceleráciu výpočtov
v oblasti počítačového videnia
- Tento prínos je ďalším teoretickým prínosom, pričom návrh architektúry vychádza na
základe preukázaných výhod z harvardskej architektúry. Vďaka východiskovej
harvardskej architektúre je sprístupňovanie dát a inštrukcií v navrhovanej architektúre
rýchlejšie a zabraňuje chybnému načítaniu dát.
Implementácia a experimentálne overenie navrhnutej špecializovanej architektúry
procesora Covitor
- Ide o hlavný praktický prínos, ktorý vychádza z teoretického návrhu architektúry
špecializovaného procesora pre akceleráciu výpočtov v oblasti počítačového videnia.
Preukázanie funkcionality navrhnutej architektúry špecializovaného procesora Covitor
- Na základe uvedenej simulácie a experimentálneho overenia bolo preukázané správne
fungovanie navrhnutej architektúry, ktorá je zameraná na urýchlenie výpočtov pri

89
spracovaní obrazu. Akcelerácia výpočtov v oblasti počítačového videnia umožňuje
lineárne zvyšovanie výkonu čipu v závislosti od počtu jadier.
Spracovanie obrazu s využitím špecializovanej architektúry s možnosťou dosiahnutia až
16-násobného urýchlenia
- Simulácia preukázala, že 16-jadrový procesor Covitor urýchľuje výpočty
pri spracovaní záťaže až 16-násobne v závislosti od použitia rovnomerného alebo
nerovnomerného rozloženia záťaže.
8 ZÁVER
Realizované simulačné experimenty jednoznačne preukázali funkčnosť navrhnutej architektúry,
pričom sa preukázala efektívnosť spracovania obrazu z hľadiska urýchlenia výpočtov pri spracovaní
obrazu, tak ako bolo navrhnuté.
Využitie viacerých jadier pri spracovaní obrazu umožnilo zrýchlenie výpočtov z hľadiska času
v lineárnej závislosti od počtu jadier, pričom je možné dosiahnuť až 16-násobné zrýchlenie za použitia
rovnomerného rozloženia záťaže.
Počas simulácie spracovania obrazu procesorom Covitor sa preukázalo, že akcelerácia výpočtov je
závislá od spôsobu rozloženia záťaže, pričom rovnomerne rozloženie záťaže je efektívnejšie, keďže
umožňuje väčšie zrýchlenie ako nerovnomerné rozloženie záťaže.
Špecializovaná architektúra je obmedzená kapacitou pamäte, z dôvodu zjednodušenia simulácií, avšak
do budúcna je možné pamäte rozšíriť podľa potrieb. Taktiež je daná architektúra obmedzená len na
základné operácie spracovania obrazu, pričom pri zavedení komplikovanejších metód (hľadanie
kostry, osem okolie) by boli potrebné rozsiahlejšie úpravy vykonávacej jednotky.
Akcelerácia výpočtov nasadením viacjadrovej architektúry nie je úplne lineárna, keďže pri stálom
zvyšovaní počtu jadier dochádza k oneskoreniu z dôvodu času potrebného na komunikáciu medzi
jadrami a rozdistribuovaním potrebných dát. Pre určenie optimálneho počtu jadier by bolo potrebné
urobiť analýzu zaoberajúcu sa oneskorením.
POĎAKOVANIE
Táto práca bola podporovaná Agentúrou na podporu výskumu a vývoja na základe zmluvy
č. APVV-0008-10 a KEGA 008TUKE-4/2013 s názvom „Mikrolearningové prostredie pre
vzdelávanie odborníkov v oblasti informačnej bezpečnosti“.
[1]
AKHTER, S. Multi-core programming: increasing performance through software multithreading. 1. vyd. New York: Intel Press, 2006. ISBN 0-9764832-4-6.
[2]
IEEE signal processing magazine [online]. Univ Politecnica de Madrid, 2009 [cit. 2013-0218]. ISSN 1053-5888. Dostupné z:
http://web.eecs.umich.edu/~blakeg/docs/aSurveyofMulticoreProcessors.pdf
90
[3]
PARELEC 2006: International Symposium on Parallel Computing in Electrical Engineering :
13-17 September 2006, Bialystok, Poland. Multi-Core Processors: New Way to Achieve High
System Performance. 2006, č. 6. DOI: 0-7695-2554-7. Dostupné z:
http://www.researchgate.net/publication/220959927_MultiCore_Processors_New_Way_to_Achieve_High_System_Performance/file/5046351838467bcb
9f.pdf
[4]
HENNESSY, John L. Computer architecture: a quantitative approach [online]. 4th ed. San
Francisco: Morgan Kaufmann, 2007, 1 sv. (různé stránkování) [cit. 2013-06-17]. ISBN 01237-0490-1. Dostupné z:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.115.1881&rep=rep1&type=pdf
[5]
HLAVÁČ, Václav a Milan ŠONKA. Počítačové vidění. Praha: Grada, 1992, 272 s. ISBN 80854-2467-3.
[6]
MAJUMDER, Bhabatosh Chanda and Dwijesh Dutta. Digital image processing and analysis.
Eastern economy ed. New Delhi: Prentice Hall of India, 2005. ISBN 81-203-1618-5.
[7]
KUMAR, R, V ZYUBAN a D. M. TULLSEN. DEPT. OF COMPUT. SCI. & ENG.,
California Univ., San Diego, CA, USA. Interconnections in multi-core architectures:
understanding mechanisms, overheads and scaling. 2005. ISBN 0-7695-2270-X. Dostupné z:
http://delivery.acm.org/10.1145/1080000/1070004/22700408.pdf?ip=147.232.3.9&acc=ACTI
VE%20SERVICE&key=C2716FEBFA981EF1C8BCF1B5A73992B942788D9E9EDFA807&
CFID=340527944&CFTOKEN=79067881&__acm__=1371452189_ad37eb69cc49a19d1e50a
35e7cc52457
[8]
SPAA 2006: eighteenth Annual ACM Symposium on Parallelism in Algorithms and
Architectures : July 30-August 2, 2006, Cambridge, Massachusetts, USA. New York: ACM
Press, c2006. ISSN 1-59593-452-9. Dostupné z:
http://cseweb.ucsd.edu/users/swanson/papers/SPAA2006WaveScalar.pdf
[9]
NURMI, J. Processor design system-on-chip computing for ASICs and FPGAs. Online-Ausg.
Dordrecht: Springer, 2007. ISBN 978-140-2055-300.
[10]
PARKER, J.R. a Kostas Terzidis TECHNICAL EDITOR. Algorithms for image processing
and computer vision. 2nd ed. Indianapolis, Ind: Wiley Pub, 2010. ISBN 11-180-2188-6.
[11]
GONZALEZ, Rafael C a Richard E WOODS. Digital image processing. 3rd ed. Upper Saddle
River: Pearson, c2008, xxii, 954 s. ISBN 01-316-8728-X.
[12]
VOKOROKOS, L., B. MADOŠ, A. BALÁŽ a N. ÁDAM. Architecture of multi-core
computer with dáta driven computation model. Acta Electrotechnica et Informatica. 2010, s.
20-23.
[13]
VOKOROKOS, L. Princípy architektúr počítačov riadených tokom údajov. Košice: elfa,
s.r.o., 2008. ISBN 978-80-8086-075-2.
[14]
YOUNG, Roger. How computers work: processor and main memory. 2nd ed. S.l.: Roger
Young, 2009. ISBN 14-421-1398-7.
2(1), 2013, 91–100, DOI: 10.18267/j.aip.16
Online: aip.vse.cz
Sekce / Section:
Uplatnění systémového myšlení v analytické
fázi vývoje aplikací
Anna Exnarová1
1
Katedra systémové analýzy, Fakulta informatiky a statistiky,
Vysoká škola ekonomická v Praze
nám. W. Churchilla 4, 130 67 Praha 3
[email protected]
Abstrakt: Předkládaný článek představuje návrh uplatnění systémového myšlení
v procesu vývoje aplikace. Uvedené modely systémového myšlení čtenáři
představují možnosti jejich využití v procesu vývoje softwarové aplikace. Návrh
nediktuje tvorbu konkrétního modelu v určitý okamžik, ale navrhuje jak je možno
využít vybrané modely. Autorským záměrem je dosáhnout změny/rozšíření v
mentálním modelu čtenáře – konkrétně části, která obsahuje obraz aplikace
systémového myšlení při vývoji aplikací.
Klíčová slova: modelování, mentální modely, systémové myšlení, vývoj
informačních systémů, softwarová aplikace
Title: Applying systems thinking in the analytical stage of application development
Abstract: This paper presents the proposal for application of systems thinking in
the application development process. The models of systems thinking present to the
reader the possibility of their use and application in the software application
development process. The proposal does not mandate the creation of a specific
model at some point, but suggests how the selected models can be used. Authorial
intention
is
to
change
the
mental
model
of
the
reader
– particularly the part that contains an image of the application of systems thinking
in developing applications.
Keywords: Modelling, Mental models, Systems thinking, Development of the
information system, Software application
92
Exnarová
1 ÚVOD
Čím dále častěji se v pracovním životě v IT praxi při vývoji aplikací setkávám se situacemi, jejichž
řešení běžným analytickým přístupem nepřináší žádoucí výsledky. I přesto, že neustále dochází
k vývoji metodik, technik, nástrojů, přístupů v dílčích činnostech a procesech vývoje informačních
systémů, dle dlouhodobých výzkumů se ukazuje, že výsledky nejsou uspokojivé. Vývoj informačních
systémů a aplikací je poměrně drahý a jeho výsledky jsou nepředvídatelné. [10] Výsledná zpráva
výzkumného projektu „CHAOS“ Standish Group z roku 2011 [10] dokladuje, že více jak polovina
projektů vývoje informačních systémů jsou neúspěšné. Jedná se o projekty z let 2002 až 2010, mezi
kterými pouze 37% bylo vyhodnoceno jako úspěšné. Bohužel 19% je zcela neúspěšných, přičemž
z tohoto objemu je 50% projektů neúspěšných z toho důvodu, že nevyhovovaly byznysovým
požadavkům. V 80% případů je konstatováno, že důvodem neúspěchu projektu byla realizace
požadavků, které nebyly vhodně uchopeny a implementovány. S určitou mírou zjednodušení si
dovolím konstatovat, že neúspěchy projektů velmi úzce souvisí se schopností úspěšně definovat
požadavky a úspěšně a efektivně realizovat činnosti v analytické fázi vývoje.
Uchopení problematiky, pochopení zákazníka a jeho požadavků, vytvoření návrhu řešení je
nepochybně podchyceno v běžně používaných přístupech. Pro to, aby tyto činnosti byly efektivní
a poskytovaly očekávané kvalitní výsledky, je vhodné je propojit a současně aplikovat společně se
systémovým myšlením. To umožňuje odstranit neschopnost pracovat se systémy jako s celky, pomáhá
pochopit skutečnou podstatu problému a nalézt efektivní řešení. [9]
Následující článek předkládá návrh, jak je možné uplatnit systémové myšlení právě při vývoji
informačního systému – konkrétně se jedná o uplatnění systémového myšlení v analytické fázi vývoje
softwarové aplikace. Nástrojem pro toto uplatnění je použití modelů systémového myšlení.
2 SYSTÉMOVÉ MYŠLENÍ A VÝVOJ APLIKACÍ
Z pohledu systémového myšlení je chápání zkoumaného systému zakotveno ve způsobu komplexního
myšlení nad prvky systému, včetně jejich vazeb v rámci vnitřních i vnějších souvislostí. Dle Mildeové
[6] a [7] je základem paradigmatu „vhodnost postavení“ a schopnost myslet. Pod pojmem „vhodnost
postavení“ je chápán postoj k problému, vnímání a chápání jak problému, tak jeho okolí. Efektivní
pohled na problém je vyhledáním jakési rovnováhy vzdálenosti, tj. ani ne zblízka příliš detailní, ani ne
z velké dálky, tak aby nebyly zanedbané podstatné skutečnosti. To co vnímáme, je závislé na našem
způsobu nahlížení. Pozornost by měla být věnována nejen struktuře, ale také vzorům chování a jeho
důsledkům.
Použitím systémového myšlení pro řešení problémů lze dosáhnout přiměřeného nalezení příčin a jejich
následků, akcentování existence zpětněvazebných smyček mezi prvky v systému a jejich dopadů na
chování systému a integrace časového hlediska do popisu systému i jeho chování. Systémové myšlení
je v souladu se základními principy definovanými systémovými přístupy, kterými jsou holismus,
emergence a synergický efekt; systémová hierarchie; existence zpětné vazby; komunikace. [7]
Nutno podotknout, že při vývoji aplikace je tvůrce konfrontován se dvěma systémy: (které se ale
mohou výrazně prolínat, či dokonce překrývat)


93
za prvé zkoumá systém, nad kterým je aplikace budována;
a za druhé vlastní aplikace je novým systémem, který tvůrce vytváří.
Jako příklad uveďme aplikaci, která bude evidovat docházku zaměstnanců ve firmě (tento příklad je
používán i v dalším textu článku). Zkoumaný systém vykazuje vlastnosti, které řešitel při návrhu
aplikace musí akcentovat (např. to, zda v realitě zaměstnanci musí být fyzicky přítomni na pracovišti,
nebo mohou pracovat z domu či u zákazníka, zda je možné, aby jeden den pracovali pouze 3 hodiny
a druhý den si chybějící čas tzv. napracovali, zda je možné, aby fyzicky v objektu existovala čtecí
zařízení evidující příchody a odchody zaměstnanců).
Vytvářený systém – tedy nová aplikace, je rovněž samostatným systémem. Způsobů, jakým tento
systém může být navržen, vytvořen a následně s ním bude pracováno, je také mnoho. A rovněž i zde je
možné využít principů systémového myšlení.
2.1 PRINCIPY SYSTÉMOVÉHO MYŠLENÍ
Při zkoumání vývoje aplikací se objevují místa, která přímo ukazují na možnost aplikace systémového
myšlení. Postupně uveďme základní principy a pokusme se okomentovat jejich význam z pohledu
vývoje aplikace.
Princip holismu a emergence hovoří o tom, že na systém se nelze dívat odděleně na základě pouhé
dekompozice systému. Je potřebné sledovat jeho chování a to nejen chování izolovaných prvků, ale
v souvislostech s ostatními prvky a okolím systému, pozorovat jejich vazby a vnější i vnitřní interakce.
V případě aplikace, která je nasazována do informačního systému, jsou tyto vlastnosti akcentovány
např. v integračních testech. Aplikace může být otestována uživatelsky, ale může mít při nasazování
velké problémy, právě z důvodu interakce s ostatními komponentami informačního systému.
Příklad vzniku synergie při vývoji systému uvádí [1, str. 45], ve kterém autoři Bébr a Doucek uvádí,
že pokud řešitel na začátku definuje požadované funkce na elementární úrovni, a je vynakládáno
poměrně velké úsilí na sladění funkcí a pochopení systému. V určité fázi nastává zlomový okamžik,
kdy systém náhle začne snadno a dobře plnit požadované funkce.
Problematiku systémové hierarchie určitě zná každý analytik. Systémová hierarchie zkoumá systém
jako součást systému vyšší úrovně a naopak považuje každou jeho část za autonomní systém, který ale
na rozdíl od tradičního pojetí rozpadu pouze na části bere v potaz to, že se jedná o systémy, které mají
vazby na okolí, a vazby uvnitř systému. Vazby i struktura systému teprve společně určují chování,
vlastnosti a funkce systému. V praxi se často lze setkat se snahou rozpracovat složitou problematiku
zkoumaného systému na menší uchopitelné části, které ale jsou dále již zkoumány izolovaně.
Typickým příkladem jsou procesní modely a jejich dekompozice. Vytvoření procesního modelu
složitého zkoumaného systému vyžaduje velkou míru znalostí, dovedností, ale také zkušeností, které
analytik musí mít, aby správně dokázal vytvořit dekompozici systému, „nepřestřelil“ míru
podrobnosti, dokázal akcentovat všechny podstatné a potřebné vlastnosti systému. Mnoho začínajících
analytiků se „utopilo“ při snaze o vytvoření dokonalého procesního modelu, který byl detailní
a dopodrobna modeloval dílčí kroky procesu, ale pro vyšší úrovně pohledu byl nepoužitelný.
94
Exnarová
Regulace (příp. samoregulace) je jednou ze základních vlastností systému. Čím vyšší komplexitu
systém vykazuje, tím bohatší je také struktura zpětných vazeb. Při návrhu vyvíjené aplikace
(vyvíjeného systému) jsou běžně zabudovávány principy regulace – např. na úrovni databázových
operací jsou řešeny optimalizace a regulování výkonu. Z pohledu zkoumaného systému je existence
zpětných vazeb tím složitější, čím složitější je systém. Se zpětnými vazbami velmi úzce souvisí
schopnost prozkoumání příčin a následků a akcentování dynamiky změn.
Komunikace systémů je vlastně výměnou informací (dat) mezi prvky systému nebo jeho okolím. Pro
úplný popis systému je nutné akcentovat všechny typy komunikace, které systém vykazuje. Ve výše
uvedeném příkladu vývoje aplikace pro docházkový systém je z pohledu vyvíjeného systému nutné
uvažovat např. o formě, jakou jsou schvalovány práce mimo pracoviště, principy schvalování
odpracovaných hodin, nebo informační toky směrem od zaměstnance k personálnímu či mzdovému
oddělení. Z pohledu vyvíjeného systému jde např. o to, zda komunikace, které probíhají v realitě, bude
nově vytvářený systém plně akcentovat, nebo dojde k jejich úpravě, či v případě technické
implementace jakým způsobem budou komunikovat databázové objekty s aplikační vrstvou.
3 MODELY SYSTÉMOVÉHO MYŠLENÍ
Systémové myšlení poskytuje nástroje, které umožňují či usnadňují jeho používání. Jedním z těchto
nástrojů jsou jeho modely. V tomto článku se věnuji těmto typům modelů, které lze chápat jako
modely systémového myšlení:





mentální modely,
myšlenkové mapy,
diagram příčin a následků,
příčinně-smyčkový diagram,
diagram hladin a toků.
K tomuto výčtu uvádím dvě stručné poznámky.
1) První uvedený typ modelů (mentální modely) chápu jako nutnou součást modelů systémového
myšlení, protože bez nich nelze provádět jakoukoliv kognitivní činnost. Pokud člověk ovládá
schopnost systémového myšlení, jeho mentální modely vykazují rovněž znaky systémového myšlení.
Na druhou stranu, pokud je nevykazují, jsou tyto modely nutnou podmínkou pro vznik dalších
modelů. Tudíž se domnívám, že tento typ modelů náleží do modelů systémového myšlení.
2) Pojem model a diagram. V článku chápu model jako zjednodušenou reprezentaci, obraz reálného
systému. Diagram je vizualizací modelu.
Následující pasáž článku představuje základní charakteristiky jednotlivých typů modelů systémového
myšlení.
95
3.1 CHARAKTERISTIKY MODELŮ SYSTÉMOVÉHO MYŠLENÍ
Mentální model si vytváříme v našich hlavách a potřebujeme jej k tomu, abychom byli schopni
v realitě existovat. Zahrnuje v sobě ty vlastnosti systému, které považujeme za potřebné. Nedostatky,
které mentální modely vykazují, souvisí s jejich vlastnostmi. Jsou nekompletní, limitované
schopnostmi lidí „řídit“ a pracovat s vlastními mentálními modely, jsou nestabilní a v čase
proměnlivé, nemají jasně definované hranice a vazby, nejsou vědecké, často obsahují
„nevysvětlitelné“ charakteristiky a emocionální prvky, z části jsou nevědomé a jsou velmi obtížně
sdílené. [3] [5] [8]
Myšlenkové mapy (mentální mapy, mind mapy) umožňují vizualizovat vybranou část mentálních
modelů, umožňují vizualizovat a dokumentovat předávané informace. Myšlenková mapa je grafické
znázornění pojmů, jejich vazeb a souvislostí, doplněné např. grafikou, obrázky, ikonami, barevným
odlišením. Tyto modely jsou založeny na jednom z principů přemýšlení – lidé nemyslí čistě lineárně,
ale vytváří si mapy myšlenek, které různě rozvíjí a propojují. [2] Mentální modely jsou určujícím
faktorem pro porozumění. Pokud chce jedinec řešit komplexní úlohy úspěšně, musí aktivním
kognitivním procesem trvale pracovat na korekci svých mentálních modelů i paradigmat.[8
Dnes již klasickým prostředkem pro vizualizaci příčin a následků je tzv. diagram příčin a následků,
neboli diagram rybí páteř, diagram rybí kosti, fishbone diagram, někdy také označován jako Ishikawův
diagram. Diagram slouží jako prostředek analýzy příčin a následků, v některých případech bývá
používán obdobně jako myšlenkové mapy pro sumarizaci souvisejících prvků a jejich vazeb.
Hledání příčin a následků je v západním způsobu myšlení velmi pevně zakořeněný přístup k řešení
problémů. Ať již v soukromém, profesním nebo vědeckém životě – všude jsme obklopeni výčtem
příčin a důvodů, které mají za následek nějaké chování nebo stav. A většinou se snažíme se dopátrat
úplného výčtu – čím víc tím líp. Jedná se přitom o hledání jednoduchých kauzálních vztahů,
jednosměrného a bez jakéhokoliv vymezení vzájemného působení mezi příčinami a důsledky. Také
zde neexistuje akcent na zpětné působení od následku k příčině. Při modelování problémové situace je
absolutně zanedbána skutečnost, že důsledek může mít velký vliv i na původní příčiny. [4]
Příčinně smyčkové diagramy (causal loop diagram, CLD) umožňují modelovat příčinnosti a tendence
vývoje. Diagram kauzálních smyček je nástrojem pro vizualizaci a následnou analýzu vzájemných
vlivů proměnných v modelech systémové dynamiky. Vzájemné vztahy proměnných usnadňují
pochopení a kvantifikaci funkcí komplexních systémů.
Diagram hladin a toků (Stock and flow diagrams, SFD) slouží k vyjádření vývoje proměnných v čase.
Základními stavebními kameny tohoto diagramu jsou: hladiny (znázorňují stavy – prvky systému,
charakterizující stav systému, zároveň reprezentují i zpoždění); a přítoky a odtoky s ventily
(vyvolávají změny hladin dané nastavením parametrů).
Poslední dva typy (příčinně smyčkové diagramy a diagramy hladin a toků) bývají často uváděn y jako
modely systémové dynamiky. Systémové myšlení a systémovou dynamiku chápu jako dvě samostatné
disciplíny, které mají vzájemný přesah. V případě, že modely obsahují i simulační prvky, náleží do
disciplíny systémová dynamika.
96
Exnarová
3.2 MODELY SYSTÉMOVÉHO MYŠLENÍ V ANALYTICKÉ FÁZI VÝVOJE
APLIKACE
Pro výše uvedené typy modelů systémového myšlení uvádí následující kapitola stručnou
charakteristiku ve vztahu k vývoji aplikací – a to jak z pohledu vyvíjeného systému, tak z pohledu
zkoumaného systému.
3.2.1
MENTÁLNÍ MODELY
Prvním modelem, který v procesu vývoje aplikace vzniká, je mentální model. Vzniká nejdříve
v myslích zadavatelů, kteří tvoří zadání a poptávají možnosti pro řešení jejich problému. Rovněž
kognitivním procesem vznikají modely realizátorů, kteří zadání studují, následně vytváří analýzy,
navrhují řešení, implementují řešení, testují či vytvořenou aplikaci nasazují.
Kvalita těchto modelů je klíčová pro celý proces vývoje aplikace. Je klíčová pro zabezpečení
komunikace. Nedostatky mentálních modelů jsou často omezujícím prvkem pro dosažení
požadovaných výsledků. Mentální modely jsou používány napříč celým procesem vývoje aplikace.
V modelovém příkladu je klíčovou osobou analytik, který má vytvořit základní koncepci návrhu
aplikace pro docházku. Tento analytik dosud celý život pracoval na pozici zaměstnance, vždy
docházel pravidelně na pracoviště a nikdy se nesetkal se situací, kdy pracuje dopoledne z domu
a odpoledne vyjíždí k zákazníkovi. Jeho mentální model budoucí aplikace obsahuje na začátku pouze
jednu variantu – v aplikaci postačuje evidovat příchod a odchod na/z pracoviště. Změna této části
mentálního modelu vyžaduje detailní znalost zkoumaného systému. Zároveň ale také schopnost
a ochotu analytika měnit svůj mentální model na základě nových poznatků. Pouhým zjištěním, že
realita se odlišuje od mentálního modelu, je často nedostatečná. Lidský mozek musí tuto informaci
dostatečně zpracovat, tak aby byl schopen svůj mentální model změnit.
3.2.2
MYŠLENKOVÉ MAPY
Myšlenkové mapy jsou modely, které pomáhají jejich tvůrcům, ale také uživatelům, lépe „přemýšlet“
– tj. efektivněji pracovat se svými mentálními modely a lépe je upravovat. Z pohledu analytické fáze
vývoje aplikace tento typ modelu umožňuje:






popsat potřeby, které má aplikace řešit;
deklarovat důvody vzniku aplikace;
v případě složitějších interakcí dokumentuje očekávané potřeby uživatelů;
popisuje chování aplikace (vytvářeného systému);
mapuje dotčené komponenty informačního systému, či okolí aplikace;
nastiňuje možné vazby na okolí.
Tento typ modelu by neměl pouze dokumentovat, ale také by měl ověřit, zda to, když „někdo říká, že
něco potřebuje“, je skutečnou potřebou. Zda existující mentální modely jsou založeny na reálné
potřebě, anebo jsou z nejrůznějších důvodů modifikovány a dopady těchto modifikací jsou nežádoucí.
Rovněž by měly pomoci ověřit, že mentální modely – a z nich vzniklé zadání, či popis budoucí
aplikace, jsou úplné.
97
Z těchto modelů může plynout potřeba redefinice nebo doplnění výčtu požadavků na aplikaci, úprava
zadání. Tvořením a následnou diskusí lze ověřit, zda je realizován požadovaný systém. Přínosy
existence těchto modelů jsou (či mohou být):







3.2.3
revize požadavku na vytvoření systému,
revize rozsahu projektu a cíle,
revize (doplnění nebo zrušení) seznamu požadavků,
opětovná diskuse se zadavatelem o cílech a očekáváních,
zjištění potřeby externích konzultací o okolí systému, o kterém nemáme dostatek informací,
vytipování parametrů, které vyplývají ze specifikace požadavků, a které budou použité pro
tvorbu případů užití,
identifikace bodů, které je případně nutné zpracovat pomocí vybrané notace procesního
modelování.
DIAGRAM PŘÍČIN A NÁSLEDKŮ
Diagram rybí páteře umožňuje popsat příčiny a následky chování systémů či možné stavy při řešení
konkrétního problému. V kontextu vývoje aplikace v analytické fázi by tento model měl obsahovat
popis příčin problémů, které by měl vyvíjený SW řešit. Při tvorbě tohoto typu diagramu je velmi
důležitým prvkem ujasnění skutečných příčin a zmapování jejich možných následků.
Použitím tohoto typu modelu může vyplynout nutnost dalších změn mimo plánovaný vývoj aplikace.
Příkladem může být zjištění, že aplikace evidující docházku zaměstnanců nemůže mít nastaven limit
8 odpracovaných hodin za den. Důvodem je existence přesčasů, které zaměstnanci vykazují. Příčinnou
přesčasů jsou různé situace, jejichž zmapování umožní v aplikaci jejich evidenci (v případě, že tento
požadavek se ukáže jako relevantní, bude následně možné vytvořit např. statistiku, proč jsou práce
přesčas využívány). Přínosy existence tohoto typu modelu mohou být:



3.2.4
revize rozsahu projektu a cíle,
opětovná diskuse se zadavatelem o cíli a očekáváních.
PŘÍČINNĚ-SMYČKOVÝ DIAGRAM
Pohled na entity, veličiny, parametry, či části systému a jejich vzájemné vztahy, vazby a procesy
umožňuje modelovat příčinně-smyčkový diagram. Tento typ diagramu umožňuje:





identifikovat a modelovat klíčové parametry, které by systém měl ovlivňovat a naplňovat,
identifikovat posilující a balanční smyčky, které popisují principy chování systému
a umožňují tak snáze najít efektivní způsoby řešení problémů,
modelovat vazby systému na okolí,
podporovat vyhledávání skrytých, nezjevných, nebo nepřímých interakcí,
v případě několika diagramů z různých úrovní pohledu vybudovat odpovídající model
hierarchie dílčích částí systémů,
98
Exnarová

zachytit vlastnosti, vnitřní závislosti, systémovou hierarchii, procesy uvnitř systému i celé
organizace.
Klasické modelování entit často ohraničuje pozornost pouze na vnitřní vazby systému.
Příčinně-smyčkový diagram podporuje modelování a přemýšlení o vazbách systému na okolí
a pomáhá přemýšlet o procesech a vztazích v příčinných i zpětně-vazebních smyčkách.
V modelovém příkladu je díky tomuto diagramu např. možno zjistit požadavky na reporty, které
aplikace bude poskytovat. Ty se odvíjí od uživatelů. Určitě mezi standardními uživateli bude
personální oddělení, nadřízení sledovaných pracovníků a vedení firmy, ale také např. státní instituce
a dohledové orgány.
Přínosy existence tohoto diagramu jsou:






3.2.5
revize rozsahu projektu,
revize (doplnění nebo zrušení) seznamu požadavků,
opětovná diskuse se zadavatelem o cílech a očekáváních,
identifikace entit, které následně budou vystupovat v logickém modelu (příp. jejich verifikace,
pokud je identifikace provedena na základě seznamu požadavků),
nalezení kritických procesních bodů, které je vhodné modelovat pomocí specializované notace
procesního modelování.
DIAGRAM HLADIN A TOKŮ
Detailnější prozkoumání entit, jejich vazeb z pohledu systémového myšlení je možné pomocí
diagramu hladin a toků. V předešlých krocích se postupně definovaly entity, vytipovaly se vazby mezi
entitami i mezi entitami a okolím systému, byly identifikovány příčiny a následně popsány zpětné
i příčinné vazby. Následuje diagram hladin a toků, který umožňuje:





podrobněji popsat a specifikovat klíčové parametry, které by systém měl ovlivňovat
a naplňovat (některé z těchto parametrů byly identifikovány v příčinně-smyčkovém
diagramu),
podrobněji dokumentovat vazby, které v systému působí,
konkretizovat působení balančních a posilujících smyček ve smyslu identifikace parametrů,
pomocných proměnných a konstant, které v těchto procesech působí,
vytvoření simulací, na základě kterých je možné podrobně specifikovat chování systému za
konkrétních podmínek,
identifikovat stavy systému, potažmo vybraných entit.
Příkladem pro tento typ diagramu je např. modelování stavu zaměstnance z pohledu vykázaných hodin
– nevykazuje, má vykázáno, má uzavřen pracovní týden, atd. Pochopení těchto stavů a parametrů,
které tyto stavy ovlivňují, jsou klíčové pro správné nastavení např. stavových modelů a použití stavů
při implementaci.
Přínosy existence tohoto diagramu jsou:





99
identifikace entit, které následně budou vystupovat v logickém modelu (příp. jejich verifikace,
pokud je identifikace provedena na základě seznamu požadavků),
identifikace klíčového parametru – tak může dojít k nutné revizi požadavků a cílů,
vliv na identifikaci kritických faktorů,
identifikace parametrů a jejich vliv na entity systému,
simulací ověřené a potvrzené očekávané hodnoty, identifikace potřebných úprav návrhu
a designu systému, nebo změna způsobu implementace.
4 ZÁVĚR
Z výše uvedených dílčích přínosů použití jednotlivých typů modelů systémového myšlení je možné
generalizovat globální přínosy, které uplatnění systémového myšlení v analytické fázi vývoje aplikace
má.
Systémové myšlení poskytuje nástroje na to, jak pracovat s komplexními systémy a řešit jejich
problémy. Vývoj informačních systémů či dílčích aplikací je nepochybně disciplínou komplikovanou
a komplexní. Využitím principů systémového myšlení za pomoci použití jejich nástrojů (tj. modelů),
by bylo možné docílit efektivnějších a uspokojivějších výsledků.
Uvedené modely jsou rozšířením oproti stávajícím a běžně používaným modelům při vývoji aplikací
(např. UML nebo procesní modely). Jejich souběžné použití by mohlo vykazovat významné
synergické efekty. Domnívám se, že aplikací systémového myšlení do vývoje informačních systémů
a spojením tradičních modelů s modely systémového myšlení vzniknou významné přínosy.
[1]
BÉBR, R., DOUCEK, P., 2005. Informační systémy pro podporu manažerské práce. 1. vyd.
Praha: Professional Publishing, 2005, 223 s. ISBN 80-864-1979-7.
[2]
BUZAN, T., B., 2011. Myšlenkové mapy: probuďte svou kreativitu, zlepšete svou paměť,
změňte svůj život. Vyd. 1. Brno: Computer Press, 2011, 213 s. ISBN 978-80-251-2910-4.
[3]
COSTELLO, W., 2007: Computer_Based Simulations as Learning Tools: Changing Student
Mental Models of Real-Word Dynamical Systems; Creative Learning Exchange. [online].
2001. [cit. 2013-03-10]. Dostupné z:
http://www.clexchange.org/ftp/documents/Implementation/IM200104ChangingStuMentMod.pdf
[4]
EXNAROVÁ, A. Uplatnění systémového myšlení v analytické fázi vývoje softwaru. Disertační
práce, VŠE FIS, Praha, 2013.
[5]
CHERMACK, T. J., 2003. Mental Models in Decision Making and Imlications for Human
Resource Development; SAGE Publications, Advances in Developing Human Resources, Vol.
5, No. 4, 408-422, [online]. 2003. [cit. 2013-03-12]. Dostupné z :
http://adh.sagepub.com/cgi/content/abstract/5/4/408
[6]
MILDEOVÁ, S., DALIHOD, M., EXNAROVÁ, A, 2012. Mental Shift Towards Systems
Thinking Skills in Computer Science. Journal on Efficiency and Responsibility in Education
100
Exnarová
and Science [online], 2012, roč. 5, č. 1, s. 25–35. ISSN 1803-1617. Dostupné z:
http://www.eriesjournal.com/_papers/article_165.pdf
[7]
MILDEOVÁ, S., a kol., 2007. Tvorba manažerských simulátorů: vaše virtuální firma.
Oeconomica, Praha, 2007. ISBN 978-80-245-1286-0.
[8]
MOLNÁR, Z., MILDEOVÁ, S., ŘEZANKOVÁ, H., BRIXÍ, R. KALINA, J., 2012. Pokročilé
metody vědecké práce. 1. vyd. Praha: Profess Consulting s.r.o., 2012. ISBN 978-80-7259-0643.
[9]
SENGE, P. M., 1995. Piata disciplína manažmentu, Systémové myslenie predpoklad rozvoja
organizácií, Open Windows, Bratislava, 1995, ISBN 80-85741-10-5.
[10]
SCHWABER, K., SUTHERLAND, J.V. The Crisis in Software: The Wrong Process Produces
the Wrong Results. Software in 30 days: how agile managers beat the odds, delight their
customers, and leave competitors in the dust. Hoboken, N.J.: John Wiley, 2012, s. 14. ISBN
978-1-118-20666-9.
2(1), 2013, 101–121, DOI: 10.18267/j.aip.17
Online: aip.vse.cz
Sekce / Section:
Optimalizácia monitorovania sieťovej prevádzky
František Jakab1, Adrián Pekár1, Peter Feciľak1, Miroslav Michalko1
1 Katedra počítačov a informatiky, Fakulta elektrotechniky a informatiky
{frantisek.jakab, adrian.pekar, peter.fecilak, miroslav.michalko}@tuke.sk
Abstrakt: Tento príspevok sa zaoberá otvorenými problémami vyskytujúcimi sa
pri pasívnom prístupe merania sieťových charakteristík. Opisuje najpoužívanejšie
prístupy merania sieťových parametrov ako aj charakteristiky, ktoré sa pri
monitorovaní najčastejšie sledujú. Hlavným cieľom tohto príspevku je predstavenie
konceptuálneho návrhu riešenia opísaných problémov, ktorý by sa mal docieliť
automatizovaným prispôsobením exportu záznamov o tokoch prevádzky
k aktuálnemu stavu siete.
Klíčová slova: pasívne meranie, aktívne meranie, monitorovanie sieťovej
prevádzky, tok, IPFIX
Title: Optimization of Network Traffic Monitoring
Abstract: This paper deals with problems which occur in passive measurement
of network characteristics. It describes the most used approaches of measuring
network parameters as well as those properties, which are most frequently
monitored. The main aim of this paper is to introduce a conceptual design of
a solution for the discussed problems, which should be achieved by automated
adapting of flow records export of traffic to the actual state of the network.
Keywords: Passive measurement, active measurement, network traffic monitoring,
flow, IPFIX
102
Jakab et al.
1 ÚVOD
Hlavným prostriedkom komunikačnej a informačnej infraštruktúry počas posledných rokov sa stal
internet. Komunikačné siete boli pôvodne navrhnuté na nezávislé prenášanie rôznych typov údajov, t.j.
rádio pre audio, televízor pre video a pod. Od jeho objavenia počet pripojených používateľov
a počítačov výrazne rastie, čo vedie k neustálemu zvyšovaniu zložitosti a náročnosti sieťovej
prevádzky. V dôsledku veľkého množstva používaných multimediálnych a distribuovaných aplikácií
boli vyvinuté konvergované siete. Na rozdiel od klasických komunikačných sietí sú tie dnešné,
konvergované, schopné súčasného prenášania údajov rôznych typov, akými sú video, hlas a dáta.
Jednou z najdôležitejších výziev konvergovaných sietí je zvýšená obťažnosť ich riadenia.
Na zabezpečenie výkonnosti, bezpečnosti a spoľahlivosti týchto sietí sa využívajú rôzne merania
a analýzy, ktoré sa kvôli nárastu požiadaviek sieťovo-orientovaných aplikácií používajú stále vo
väčšej a väčšej miere. Napriek značnému úsiliu vedecko-výskumnej komunity, veľa problémov v
oblasti monitorovania sieťových charakteristík zostáva otvorených.
V nasledujúcich kapitolách bude predstavená stručná motivácia pre monitorovanie sietí a ich
vlastností. Následne budú opísané najdôležitejšie charakteristiky, ktorých meranie je z pohľadu
monitorovania užitočné. Predmetom záujmu bude aj definícia a prehľad rôznych prístupov
monitorovania a merania prevádzkových charakteristík. V pokračovaní sa predstavia otvorené
problémy, ktoré sa pri monitorovaní prevádzkových charakteristík vyskytujú, ako aj výsledky
experimentu vykonaného pre overenie prítomnosti vybraných problémov. Záverečná kapitola
poskytuje konceptuálny návrh metódy pre vyriešenie opísaných problémov.
2 MOTIVÁCIA
Počítačové siete sa stali neoddeliteľnou súčasťou každodenného života. Využívajú sa pre osobnú
komunikáciu, zdieľanie údajov, verejné šírenie správ, prenášanie privátnych údajov, kolaboráciu,
telefonovanie, podnikanie, vzdelávanie, nakupovanie, zábavu, socializáciu, atď. Zdrojom týchto
aktivít sú v drvivej väčšine používatelia a aplikácie, ktoré používajú. Výsledkom je obrovský objem
údajov, ktoré tvoria prevádzku počítačových sietí. Pri prevádzke s takou širokou a rozmanitou
charakteristikou, dôležitým aspektom počas návrhu, správy a optimalizácie dnešných komplexných
a vysoko-rýchlostných počítačových sietí je meranie a monitorovanie ich rôznych vlastností. Meranie
a monitorovanie sietí poskytuje významné informácie pre používateľov, poskytovateľov služieb (ISP),
výskumníkov alebo iných členov verejnej a vedeckej komunity. Na základe týchto informácií je
následne možné zabezpečiť kvalitu, výkonnosť a plnohodnotnú funkčnosť počítačových sietí, ich
služieb a aplikácií.
Pre monitorovanie sieťovej prevádzky existuje aj veľa ďalších dôvodov. Charakteristiky vyťaženia
siete výrazne ovplyvňujú sieťové komponenty a protokoly. Výkonnosť smerovačov napríklad
podstatne závisí od štatistických vlastností prevádzky a rozdelení veľkosti paketu. Ďalej môže správna
charakteristika topológie značne prispieť pri identifikácii miest potenciálneho výskytu výkonnostných
problémov.
103
Meranie sieťových charakteristík je dôležité aj v prípade vedecko-výskumnej činnosti. Väčšina
výskumov sa zameriava na získanie znalostí o dynamike sietí. Pochopenie dynamiky sieťovej
prevádzky je nevyhnutné z pohľadu budovania rôznych sieťových modelov pre účely riešenia
problémov týkajúcich sa vyhodnocovania, výkonnosti, zabezpečenia alebo optimalizácie sietí [6].
Avšak zhromažďovanie reprezentatívneho súboru nameraných dát nie je jednoduchý proces.
S ohľadom na túto skutočnosť, autori v príspevku [5] poskytujú detailné vysvetlenie problémov
týkajúcich sa simulácie internetu, z ktorých sa niektoré vyskytujú aj v prípade merania sieťovej
prevádzky. Tieto problémy sú napríklad veľkosť a heterogénna povaha sieťovej prevádzky, neustále sa
zvyšujúci počet sieťovo-orientovaných aplikácií, rýchly a nepredvídateľný spôsob zmien v sieťach,
veľkosť a aktuálnosť zhromaždených vzorov alebo manipulácia s odľahlými hodnotami meracích
procesov.
Aj keď počítačové siete patria medzi neustále sa vyvíjajúce oblasti informačných technológií, počet
nových pripojení — či už v podobe zariadení alebo používateľov — a prudký nárast objemu, ako aj
obsahu prevádzky robia ich monitorovanie čoraz zložitejším. Napriek tomu, že súčasné siete obsahujú
množstvo sofistikovaných nástrojov pre detekciu a signalizáciu rôznych chýb a porúch, stále existuje
skupina takých udalostí, ktoré väčšinou zostanú neodhalené [2]. Tieto udalosti sa nazývajú tiché
poruchy (silent failures), medzi ktoré, okrem iných, patria najmä konfiguračné chyby (nesprávne
nastavenia ACL), smerovacie anomálie (smerovacie slučky) alebo nečakané drobné závady
v smerovačoch (neschopnosť smerovača detegovať svoju internú chybu). Všetky tieto udalosti môžu
viesť k nepriaznivému ovplyvneniu výkonnosti počítačových sietí. Nedostatok schopnosti
zachytávania týchto javov je evidentným dôkazom potreby vylepšovania monitorovacích a meracích
mechanizmov.
3 MONITOROVANIE SIEŤOVEJ PREVÁDZKY
V terminológií počítačových sietí spolu s pojmom ‘monitorovanie’ často vystupuje aj ‘meranie’.
V niektorých prípadoch sa o meraní dokonca hovorí, akoby bolo neoddeliteľnou súčasťou
monitorovania [4]. Faktom je, že aj meranie, aj monitorovanie predstavuje rozsiahlu oblasť
počítačových sietí, pričom spolu tvoria nenahraditeľný pilier mechanizmu, ktorý za dnešnými vysokorýchlostnými počítačovými sieťami stojí. Súvislosť medzi monitorovaním a meraním je veľmi
jednoduchá. Bez merania charakteristík sieťovej prevádzky — a následného vyhodnotenia
nameraných dát — by nebolo možné uskutočniť monitorovanie sietí. Bez monitorovania by následne
nebolo možné vykonať úlohy akými sú kontrola, správa, zabezpečenie alebo optimalizácia
počítačových sietí. Kým v prípade merania alebo monitorovania sietí sú najdôležitejšími entitami
sledované prevádzkové charakteristiky, v prípade vyhodnocovania majú najvýznamnejšiu úlohu
aparáty zvolené z oblasti matematických vied [4]. Preto pri monitorovaní a s ním súvisiacimi úkonmi
je potrebné im venovať výnimočnú pozornosť.
Pojem monitorovanie siete slúži na opis činnosti takého systému, ktorý neprerušene sleduje celú sieť
a jej prevádzku. Hlavnou charakteristikou takého systému je, že v prípade objavenia chýb, výpadkov
alebo iných nezvyčajných javov okamžite upozorní (napr. prostredníctvom e-mailu) správcu siete.
Okrem nepretržitého sledovania sa monitorovanie využíva aj v správe sieťovej prevádzky, rôznych
prístupov, komponentov (uzlov) a pod. Tieto, už aj tak komplexné úkony, ďalej komplikuje
104
Jakab et al.
topologická (fyzické prepojenie všetkých komponentov) a výpočtová (smerovanie a riadiace úlohy
sieťových komponentov) zložitosť dnešných konvergovaných sietí. Nasadenie monitorovania nie je
obmedzené typom siete, t.j. prakticky sa môže sledovať ľubovoľná sieť, od lokálnych (LAN) alebo
bezdrôtových, cez virtuálne privátne (VPN), až k metropolitným (MAN) alebo rozľahlým (WAN)
sieťam. Monitorovanie sa neobmedzuje ani na jednotlivé sieťové komponenty (prepínače, smerovače,
servery, IP telefóny, atď.). Monitorovanie siete sa vykonáva pomocou softvérových aplikácií
a nástrojov. Pomocou týchto softvérov sa môžu jednoducho určiť metriky súvisiace s výkonom sietí,
identifikovať jednotlivé aktivity a ich vplyv na softvérové a hardvérové prostriedky. Monitorovanie je
nenahraditeľným nástrojom aj v detekcii a predchádzaní bezpečnostných hrozieb.
Ako bolo na začiatku spomenuté, monitorovanie počítačových sietí je podmienené zberom údajov.
Táto činnosť sa označuje ako meranie charakteristík počítačových sietí a spolu s vyhodnocovaním
nameraných hodnôt tvoria najdôležitejšie súčasti monitorovania.
4 MERANIE PREVÁDZKOVÝCH CHARAKTERISTÍK
Pri meraní prevádzkových parametrov sietí sa rozlišujú tri hlavné prístupy: aktívne, pasívne
a kombinované. V súčasnosti sú najpoužívanejšie aktívne a pasívne prístupy merania. Obe poskytujú
iné typy výsledkov, pričom aj aktívne, aj pasívne meranie sa zvyčajne používa v odlišných meracích
zostavách a pre rôzne účely.
Okrem týchto prístupov, v poslednej dobe sa rozšírilo aj takzvané kombinované alebo semi-aktívne
meranie, ktoré pri zisťovanie sieťových charakteristík zlučuje kladné vlastnosti aktívneho a pasívneho
prístupu merania.
4.1 AKTÍVNE MERANIE
Aktívny prístup merania parametrov sietí je založený na schopnosti vložiť testovacie pakety (sondy)
do monitorovanej siete. Sledovaním a následným meraním týchto paketov je možné dostať operatívnu
viditeľnosť siete. Príklad aktívneho prístupu merania je uvedený na Obrázku 1. Obrázok opisuje
situáciu, keď meranie charakteristík a ich export sa vykonáva z miesta, ktoré je odlišné od
zhromaždovacieho bodu. Takáto situácia sa často vyskytuje v prípade merania charakteristík o IP
tokoch sieťovej prevádzky s dvoma a viacerými meracími/exportovacími bodmi.
V niektorých prípadoch sa testovacie pakety posielajú priamo k serverom alebo aplikáciám. Takýmto
spôsobom je možné dostať prehľad stavu služieb v sieti. Z toho je možné odvodiť nasledujúce dve
vlastnosti:


aktívne meranie si vyžaduje generovanie dodatočnej prevádzky,
prevádzka a jej parametre sú umelé.
Objem a iné charakteristiky generovanej prevádzky sú ľubovoľne prispôsobiteľné, pričom pre získanie
zmysluplných výsledkov stačí aj relatívne malý objem prevádzky. Aktívne meranie poskytuje
explicitnú kontrolu generovania paketov pre rôzne meracie scenáre. Okrem iných zahŕňa kontrolu nad
vlastnosťou generovania prevádzky, technikami vzorkovania, veľkosťou a typom paketov, trás,
105
funkcií, atď. Jedným nežiadaným vedľajším účinkom aktívnych meraní môže byť zvýšenie záťaže
siete, ktoré môže viesť k ovplyvneniu alebo úplnému znehodnoteniu výsledkov meraní. Ďalšou
nevýhodou aktívneho merania je, že poskytuje málo informácií o danom meracom bode. Namiesto
toho ale poskytuje rôzne typy charakteristík o spojení medzi dvoma uzlami.
Obr. 1. Architektúra aktívneho prístupu merania.
Väčšinou sú to výkonnostné charakteristiky, ako napríklad:




doba obehu paketu (RTT),
priemerná stratovosť paketov,
šírka pásma spojenia,
priepustnosť paketov.
V niektorých prípadoch môžu aktívne merania poskytnúť informácie aj o časoch asymetrického
oneskorenia alebo zmien v cestách smerovania medzi uzlami. Tieto charakteristiky si ale vyžadujú
rozšírenie meracej zostavy o ďalšie podporné mechanizmy alebo dodatočnú kompenzáciu hodnôt.
4.2 PASÍVNE MERANIE
Pasívny prístup merania predstavuje taký proces, ktorý si nevyžaduje generovanie dodatočnej alebo
zmenu existujúcej prevádzky. Meraná prevádzka je teda generovaná len pripojenými používateľmi
a aplikáciami siete. Príklad pasívneho prístupu merania je uvedený na Obrázku 2. Pasívne meranie sa
spravidla vykonáva nasledujúcimi prostriedkami:


Sieťové komponenty (smerovače, prepínače, koncové zariadenia) so zabudovaným
mechanizmov zachytávania informácií o prevádzke. Takéto mechanizmy predstavujú
napríklad protokoly NetFlow [3], SNMP [1] alebo RMON [21].
Softvérové nástroje (BEEM [9], Wireshark [24], atď.) určené pre zber a spracovanie
informácií o údajoch v sietí.
106
Jakab et al.
Zhromažďovanie nameraných údajov od týchto prostriedkov sa vykonáva periodicky. Na základe
vyhodnotenia získaných informácií sa určujú charakteristiky siete (výkonnosť, stav a pod).
Výhodou pasívneho prístupu je meranie reálnej prevádzky. Ďalšou výhodou je, že na rozdiel od
aktívneho merania, proces samotného pasívneho merania nezvyšuje zaťaženie prevádzky siete.
Obr. 2. Architektúra pasívneho prístupu merania.
Keďže spomenuté dotazovanie a zhromažďovanie nameraných údajov môže priniesť isté zvýšenie
prevádzky (najmä v prípade zachytávania informácií o každom pakete), táto výhoda je len relatívna.
Riešenie predstavuje vyhradenie osobitných liniek pre merané a namerané údaje. Takýmto spôsobom
sa informácie súvisiace s pasívnym meraním nebudú miešať s reálnou prevádzkou, čo v konečnom
dôsledku vedie k neovplyvneným výsledkom merania prevádzkových parametrov. Vzhľadom na to, že
sa v niektorom prípade sleduje každý paket v sieti, pasívne meranie môže čeliť problémom týkajúcich
sa súkromia alebo bezpečnosti informácií [18, 19].
Na rozdiel od aktívneho merania, pasívne meranie poskytuje detailný súbor informácií o meracom
bode siete. Tieto informácie sú napríklad:




z akých typov údajov, služieb alebo protokolov pozostáva prevádzka (traffic mix),
intenzita paketov,
časovanie paketov,
oneskorenie paketov.
Okrem vlastností o reálnej prevádzke, pasívne meranie môže poskytnúť informácie aj o infraštruktúre
siete. Takýto typ pasívneho merania pozostáva zo zachytávania a analýzy riadiacej roviny prevádzky,
napríklad smerovača. Pasívne merania infraštruktúry umožňujú napríklad protokoly BGP [22] alebo
OSPF [14].
107
4.3 KOMBINOVANÉ MERANIE
Meranie infraštruktúrnych alebo topologických charakteristík je často účinnejšie s kombináciou
rôznych prístupov meraní. Napríklad nevýhodou aktívneho merania je veľký počet testovacích
paketov pre zistenie už aj relatívne jednoduchých charakteristík (mapovanie jediného autonómneho
systému). Množstvo testovacích paketov je možné redukovať, napríklad, pasívnym meraním. V tomto
prípade, kombináciou aktívneho a pasívneho merania sa obmedzeniam aktívneho merania dá
jednoducho vyhnúť. Použitím pohľadov protokolu BGP (BGP views) je možné napríklad
identifikovať obmedzenú množinu adries, ktoré pravdepodobne patria do skúmaného autonómneho
systému [16].
Medzi kombinované typy meraní patria aj semi-aktívne, ktoré pre zisťovanie sieťových charakteristík
rozširuje existujúcu prevádzku o ďalšie informácie. Takýmito informáciami sú časová známka alebo
jedinečný identifikátor paketu. Jednou z nevýhod semi-aktívnych meraní je modifikácia paketov, ktorá
môže ovplyvniť výsledky meraní tým, že označené pakety môžu byť ďalej spracovávané.
Semi-aktívne merania sú náročnejšie na výkon meracieho bodu.
Kombináciou rôznych druhov meraní je možné skvalitniť priebeh a presnosť ich výsledkov.
Vo všeobecnosti pre zlúčené merania platí, že využívajú len pozitívne aspekty, ktoré v sebe zahŕňajú.
5 CHARAKTERISTIKY POČÍTAČOVÝCH SIETÍ
Počítačové siete charakterizuje veľa rôznych vlastností, ktoré je z pohľadu monitorovania sieťovej
prevádzky dôležité merať. Niektoré z týchto vlastností sa týkajú fyzických komponentov, iné samotnej
prevádzky počítačových sietí. Významnú skupinu predstavujú aj tie charakteristiky, ktoré vznikajú pri
interakcii fyzických komponentov a prevádzky. Ďalšou dôležitou vlastnosťou počítačových sietí sú
časové charakteristiky. Čas predstavuje jednu zo základných entít, ktorá má dôležitú úlohu v prípade
takmer každého úkonu súvisiaceho s monitorovaním sietí.
5.1 VLASTNOSTI FYZICKÝCH KOMPONENTOV
Prvú skupinu vlastností infraštruktúry predstavujú charakteristiky fyzických komponentov. Fyzické
komponenty tvoria základné prvky počítačových sietí, medzi ktoré okrem iných patria:



Linky – V prípade liniek medzi zaujímavé parametre na meranie patria propagačné
oneskorenie alebo kapacita liniek. Propagačné oneskorenie predstavuje potrebný čas signálu,
aby prešiel cez linku. Kapacita linky predstavuje maximálne dosiahnutú intenzitu prenášania
údajov.
Smerovače – Smerovače charakterizuje tiež niekoľko vlastností. Zo statického hľadiska
zaujímavými vlastnosťami smerovača sú IP adresy rozhraní, geologická poloha, typ
smerovača, podporované protokoly. Z dynamického hľadiska je možné, napríklad merať čas
potrebný na reakciu ICMP správy alebo čas potrebný na doručenie paketu.
Bezdrôtové zariadenia – Meranie bezdrôtových komponentov sa väčšinou zameriava na silu
signálu, intenzitu údajov, úroveň pokrytia, chybovosť alebo informácie týkajúce sa relácie
(session). V prípade kombinácií bezdrôtových a bežných zariadení, zaujímavými vlastnosťami
108
Jakab et al.
na meranie predstavujú metriky, ako napríklad kapacita linky, dostupná šírka pásma,
identifikácia úzkych profilov (bottleneck), atď.
5.2 PREVÁDZKOVÉ CHARAKTERISTIKY POČÍTAČOVÝCH SIETÍ
Dnešné počítačové siete sú schopné prenášať veľké množstvo údajov. Tieto údaje je možné považovať
za určitú kolekciu paketov alebo zbierku bajtov, prostredníctvom ktorých sa definuje prevádzka
počítačových sietí. Prevádzka sa zvyčajne vzťahuje na všetky druhy prenášaných údajov (video, hlas,
dáta, riadiace správy, atď.) za daný časový okamih, avšak v niektorom prípade sa môže obmedziť len
na určité prenosy, správy, záznamy alebo vybranú skupinu používateľov.
Častou požiadavkou pri monitorovaní sieťovej prevádzky je zachytávanie časových charakteristík.
Presnosť nameraných vlastností, akými sú, napríklad, doba obehu (RTT), oneskorenie alebo
výkonnosť sieťových zariadení značne závisia od meraní časových charakteristík. Kedže jednotlivé
sieťové zariadenia sú od seba po sieti často rozptýlené do značnej vzdialenosti, získavanie presných
informácií o čase môže byť náročnou úlohou. Najviac problémov sa týka presnosti hodín, na základe
ktorých sa časové charakteristiky určujú [7]. Paradoxne, pripúšťajúc existenciu presných hodín,
vzdialenosť medzi zariadeniami môže spôsobiť také komunikačné oneskorenie, ktoré môže mať
negatívny vplyv na výsledky meraní časových charakteristík.
Nakoľko výsledky sledovaných charakteristík môžu mať presnosť z výrazne odlišných časových
rozsahov, metódy merania a analýzy sa môžu značne líšiť. Napríklad pre výkonnostnú analýzu
zvyčajná presnosť je od zopár mikrosekúnd do desiatok minút a pre sieťové inžinierstvo od niekoľko
minút do niekoľko mesiacov. Za predpokladu, že každé meranie charakterizuje čas začatia
a ukončenia, teda časový rozsah, všeobecne platí, že merania v malých časových rozsahoch, t.j.
v nano-sekundových presnostiach sú oveľa náročnejšie ako merania vo väčších časových intervaloch,
t.j. v sekundových alebo minútových presnostiach.
5.2.1
PAKETY
Ako bolo vyššie uvedené, prevádzka sa zvyčajne definuje (na úrovni protokolu IP) ako zbierka
paketov za určitý časový okamih. Na spojeniach počítačových sietí nepodporujúcich pakety (napríklad
tradičné dvojbodové (Point-to-Point) telekomunikačné linky) je možné prevádzku považovať za
kolekciu bajtov, znakov alebo bitov. Z toho dôvodu sa pri reprezentácii sledovanej sieťovej prevádzky
najčastejšie využívajú vlastnosti práve týchto dvoch základných prvkov.
Najjednoduchšia metóda reprezentácie nameranej prevádzky predstavuje jej sumarizáciu na základe
nejakej vlastnosti alebo charakteristiky. Jeden spôsob sumarizácie obdržanej prevádzky predstavujú
stochastické modely [4, 23]. Ak uvažujeme len tie časy, keď paket prišiel na pozorovací bod,
t.j.
, 0, 1, . . . , potom výsledný súbor takýchto časov môže byť vyjadrený ako model
príchodového procesu (arrival process). V takomto prípade sumarizácia príchodového procesu
pozostáva z charakteristiky rozdelenia intervalov, t.j. distribučné vlastnosti súboru
, 1, 2, . . . ,
kde
≡ . Príklad takého modelu je uvedený na Obrázku 3, kde -ová os predstavuje
príchody jednotlivých paketov ( ) a -ová os reprezentuje veľkosť týchto paketov v čase (
).
5.2.2
109
TOKY
Presná identifikácia dátových položiek aplikačnej vrstvy [17] je bez analýzy obsahu paketov často
nemožná. Navyše, pre účtovanie, modelovanie alebo sumarizáciu je zhromaždenie každého paketu
súvisiaceho s výmenou údajov medzi dvomi koncovými bodmi do jednej entity oveľa dôležitejšie ako
identifikácia týchto dátových položiek. Pojem tok sa používa na vyjadrenie tejto podstaty. IP tok je
podľa štandardu IPFIX [12, 26] definovaný ako množina IP paketov prechádzajúcich pozorovacím
bodom v sieti počas určitého časového intervalu. Všetky pakety patriace do daného toku majú
spoločné vlastnosti.
Obr. 3. Príchod paketov.
Každá vlastnosť je definovaná ako výsledok funkcie aplikovanej na niektorú z častí paketu. Takýmito
časťami môžu byť:



jedna alebo viac položiek hlavičky paketu (napríklad cieľová IP adresa), hlavičky
transportného protokolu (napríklad cieľový port) alebo položky hlavičky aplikačného
protokolu (napríklad položky hlavičky RTP).
jedna alebo viac charakteristík samotného paketu (napríklad počet MPLS návestí).
jedno alebo viac polí odvodených zo spracúvania paketu (IP adresa nasledujúceho smerovača,
výstupné sieťové rozhranie).
Paket patrí do toku, ak spĺňa všetky podmienky definované vlastnosťami. IP toky je možné
aj agregovať. Agregácia je možná na základe portu, protokolu, adresy, alebo ich kombinácie.
110
Jakab et al.
5.3 CHARAKTERISTIKY VYPLÝVAJÚCE Z INTERAKCIE
INFRAŠTRUKTÚRY A PREVÁDZKY SIETE
Existuje veľa vlastností prevádzky, ktoré sú ovplyvnené stavom siete. Tieto vlastnosti môžu byť
chápané ako výsledok interakcie medzi prevádzkou a infraštruktúrou siete. Charakteristiky
vyplývajúce z tejto interakcie sa často označujú aj ako parametre súvisiace s kvalitou služieb (QoS)
[10]. Najvýznamnejšie parametre kvality služieb sú opísané v Tabuľke 1.
Názov charakteristiky
Opis
Šírka pásma (bandwidth)
Používa sa pre vyjadrenie množstva údajov,
ktoré môžu byť prenesené za jednotku času.
Stratovosť (packet loss)
Množstvo nedoručených alebo poškodených
paketov.
Jednosmerné oneskorenie (one-way delay)
Absolútna hodnota rozdielu času odoslania
paketu v jednom bode a času prijatia tohto
paketu v inom bode.
Kolísanie oneskorenia (jitter)
Je miera plynulosti procesu príchodu paketu,
ktorú je možné vyjadriť ako kolísavosť
medzičasov príchodu paketu.
Spiatočné oneskorenie (round-trip time)
Čas potrebný na odoslanie paketu od zdroja
k cieľu, jeho prijatie v cieli, okamžité spätné
odoslanie paketu z cieľa a jeho prijatie naspäť
v zdroji.
Priepustnosť (throughput)
Sa vzťahuje na mieru, ktorou je prevádzka
schopná reálne ‘tiecť’ cez sieť. Hranica
priepustnosti je všeobecne daná kombináciou
kapacitných hraníc sieťových komponentov
a nepriechodnosti zapríčineného prevádzkou.
Tab. 1. Najvýznamnejšie charakteristiky vyplývajúce z interakcie interakcie a prevádzky siete.
6 OTVORENÉ PROBLÉMY
SIEŤOVEJ PREVÁDZKY
TÝKAJÚCE
SA
MONITOROVANIA
Jednotlivé úkony súvisiace s monitorovaním a vyhodnocovaním nameraných hodnôt obklopuje veľa
problémov. Niektoré sú z nich na logickej, iné na fyzickej alebo abstraktnej úrovni. Častým
111
problémom je napríklad určenie tých bodov siete, v ktorých môžu byť merania uskutočnené [4]. Ďalší
problém predstavuje pojem času, ktorý má silný vplyv na presnosť výsledkov meraní [4, 25].
Primeraná časť týchto problémov bola za posledné desaťročie úspešne vyriešená. Vytvorili sa rôzne
techniky, metódy a nástroje pre zachytávanie a vyhodnocovanie vlastností dnešných konvergovaných
sietí. Niektoré problémy ale ostávajú naďalej otvorené.
6.1 PRISPÔSOBENIE INFRAŠTRUKTÚRY A ZARIADENÍ
Zhromažďovanie údajov na rôznych úrovniach si často vyžaduje zmeny v infraštruktúre. Je to kvôli
tomu, že pri plánovaní nie sú zohľadnené spôsoby a možnosti vykonania meraní, ale sú len
dodatočnou myšlienkou. Najväčší problém to spôsobuje v nižších úrovniach, kde je zvyčajne málo
možností na vykonanie meraní.
Vyššie, na úrovni paketov, pre zvládnutie väčšieho objemu údajov je často potrebné rozšíriť siete
o podporu špecifických zariadení. Zabezpečenie nezávislosti zhromažďovania paketov od základných
funkcionalít smerovača si môže napríklad vyžadovať pridanie sieťových odbočovačov (taps) alebo
rôznych zariadení pre pasívne monitorovanie a zrkadlenie paketov. Pre udržanie kroku s prudkým
rastom rýchlosti prevádzky je potrebné aj výraznejšie prispôsobenie na úrovni hardvéru (napríklad
pridanie rýchlejších sieťových kariet). Špeciálne karty sú ale často vyrábané len pre určitú generáciu
alebo rodinu sieťových komponentov, čo niekedy môže značne obmedziť možnosti aktualizácie
hardvérových prostriedkov a kapacít.
6.2 SYMBOLICKÝ CHARAKTER NAMERANÝCH DÁT
Medzi najdiskutovanejšie problémy pri monitorovaní v rozľahlých sieťach patrí zabezpečenie
reprezentatívnosti (symbolického charakteru) nameraných entít. Možne riešenie predstavuje posielanie
a následné sledovanie testovacích správ (sond) prostredníctvom rôznych ciest k veľkému počtu entít
– teda aktívne meranie. Entity v takomto prípade môžu byť:




zákazníci, od ktorých sú namerané údaje obdržané,
trasy, cez ktoré sú údaje prenášané,
webové stránky,
alebo špecifický typ peer-to-peer zdroja pozostávajúceho z rôznych uzlov.
Ďalší problém, ktorý súvisí s reprezentatívnosťou údajov je, že merania v rozsiahlych sieťach nad
veľkým počtom uzlov a webových stránok bez samotného prístupu k infraštruktúre je priam nemožné
vykonať. Tieto ťažkosti niekedy prehlbuje aj častá neochota zo strany sieťových administrátorov, ktorí
z bezpečnostných alebo konkurenčných dôvodov odmietajú prístup alebo monitorovanie údajov.
Rastúci počet webových klientov, vrátane používaných prehliadačov a aplikácií, zvyšuje potrebu
definovania symbolického charakteru kolekcie údajov.
6.3 OBJEM ÚDAJOV
Častým problémom pri zhromažďovaní údajov na smerovačoch alebo iných entitách infraštruktúry
(napríklad linky) je určenie objemu sledovaných údajov. Hlavnou úlohou sieťových entít je
112
Jakab et al.
zabezpečenie plynulého a rýchleho prenosu dát. V prípade dnešných konvergovaných sietí to znamená
obrovský objem údajov.
Nasadenie monitorovania prevádzky môže v niektorých prípadoch namiesto zvýšenia kvality alebo
spravovateľnosti týchto sietí vyvolať opačný účinok, t.j. zaťaženie entít alebo prevádzky. Ak sú
napríklad jednotlivé sieťové zariadenia ovplyvnené riadiacimi správami a nameranými dátami
vymieňanými medzi monitorovacím systémom a meracími bodmi, môže ľahko dôjsť k zníženiu
výkonnosti sieťových prenosov, oneskoreniu alebo dokonca aj k strate údajov. V závislosti od
protokolu vyššej úrovne (TCP/UDP), strata údajov môže, ale nemusí byť ošetrená. V takomto prípade
monitorovanie stratí na svojich výhodách a v istých prípadoch sa stáva ’nežiadúce’. Z dôvodu
zvládnutia čoraz náročnejších požiadavok vysoko-rýchlostných liniek musia byť monitorovacie
mechanizmy pravidelne optimalizované.
6.4 ASYMETRIA KAPACITY SYSTÉMOVÝCH PROSTRIEDKOV
Ďalší problém predstavuje asymetria kapacity systémových prostriedkov medzi meracím
(monitorovacím) systémom a sieťou, ktorá sa meria (monitoruje) [11]. Aj keď sa meria len malá časť
prevádzky, sieť stále obsahuje oveľa viac zariadení ako monitorovací systém. Výsledkom je
neporovnateľný rozdiel medzi výpočtovými kapacitami. Navyše, zachytávanie a uloženie informácií
o prevádzke pre neskoršiu analýzu ďalej obmedzujú parametre, akými sú šírka prenosu, rýchlosť
a kapacita pamätí, diskových polí.
Keďže v niektorých prípadoch môžu vzniknúť aj neprerušované toky prevádzky, pre zabezpečenie
bežných úloh, akými je určenie trás alebo filtrovanie, je ťažké odhadnúť nároky sieťových kariet
smerovačov [4]. Ak smerovač musí vyčleniť pre merania nejakú pevnú čiastku použiteľných
systémových prostriedkov, väčšinou to spraví na úkor iných funkcionalít (napríklad obmedzením
schopnosti zvládnutia náhlych zmien v prevádzke). V prípade, ak aj existuje hardvér schopný
sledovania primeraných častí tokov prevádzky, zhromažďovanie jednoduchších metrík ako počty
(counts) môže spotrebovať výraznú časť dostupných systémových prostriedkov. Táto asymetria si
vyžaduje budovanie efektívnych techník a prístupov monitorovania sieťovej prevádzky.
6.5 VYTVÁRANIE A EXPORT ZÁZNAMOV O TOKOCH PREVÁDZKY
Smerovače sa okrem zachytávania paketov často zúčastňujú aj vo vytváraní agregovaných informácií
o tokoch prevádzky. Agregácia je zabezpečená vytvorením záznamov o tokoch, ktoré pozostávajú
z informácií o kľúčových charakteristikách sieťovej prevádzky. Tieto záznamy sú pravidelne
exportované pre rôzne účely, ako monitorovanie prevádzkových charakteristík, účtovanie alebo správa
sietí [3, 25, 26]. Smerovače od spoločnosti Cisco sú schopné, prostredníctvom vlastného protokolu
Netflow [3], vytvárania takýchto záznamov o tokoch, ktoré obsahujú dôležité štatistiky o prevádzke
sietí. Najpoužívanejšími položkami týchto záznamov sú zdrojové a cieľové IP adresy/porty, protokol,
čas začiatku a konca toku, typ služby (ToS) alebo autonómny systém (AS). Netflow záznam sa
vytvára:


po uplynutí ľubovoľne nastaviteľného času nečinnosti koncových bodov (passive timeout),
ak jedna strana ukončí spojenie,


113
po prekročení ľubovoľne nastaviteľného času, pričom koncové body sú ešte stále aktívne
(active timeout),
ak smerovač potrebuje vyprázdniť svoj zásobník.
Napriek tomu, že záznamy o tokoch predstavujú efektívnu formu agregovaných meta-informácií,
jednoduché sledovanie veľkého počtu tokov a následné generovanie záznamov môžu značne zaťažiť
smerovač [4]. Obmedzenia pamäte a výpočtových funkcionalít v kombinácii s hlavnou úlohou
smerovača (smerovanie paketov) viedli k rôznym sofistikovaným metódam na redukciu množstva
spracovaných dát, akým sú napríklad vzorkovanie alebo sumarizácia paketov.
Podobne ako smerovače, nástroje pre zhromažďovanie záznamov o tokoch (flow collector) — ktoré sú
často nejakou externou softvérovou alebo hardvérovou súčiastkou merania — môžu mať svoju vlastnú
šírku pásma, veľkosť pamäte alebo výpočtovú kapacitu. Z toho vyplýva, že bez ich optimalizácie
môže dojsť k zahodeniu alebo strate dát [20].
6.6 MIERA CHYBOVOSTI MONITOROVACÍCH NÁSTROJOV
Väčšina súčasných monitorovacích mechanizmov pri analýze nameraných hodnôt zohľadňuje len
jednu charakteristiku tokov prevádzky [15]. Ak vyhodnotená hodnota tejto charakteristiky sa kolíše
okolo preddefinovanej hranice, z dôvodu potencionálnej hrozby môže dojsť k nesprávnym úsudkom
monitorovacieho systému. Takýto prípad môže nastať, ak prípustná hodnota šírky pásma sa kolíše
okolo štandardnej hodnoty, v dôsledku čoho monitorovací systém môže obmedziť isté funkcionality
alebo hlásiť priveľa upozornení aj v prípade, ak sa v skutočnosti nejedná o žiadnu hrozbu alebo
problém. V takomto prípade môže byť presnosť a kvalita monitorovacích mechanizmov spochybnená
[15]. Výrazný vplyv na chybovosť merania má metodika vykonávania samotného merania, kde
merací-exportovací proces nesmie ovplyvniť smerovacie procesy v danej topológii, čím by vnášal
skreslenie do výsledného hodnotenia parametrov prevádzky. Množstvo monitorovacích systémov, ako
je to aj v prípade projektu Basic Meter [9] pracuje so zrkadlenou prevádzkou z danej infraštruktúry, čo
si vyžaduje prítomnosť prvkov siete umožňujúcich toto zrkadlenie.
6.7 VYHODNOCOVANIE ÚDAJOV V REÁLNOM ČASE
Schopnosť spracovania primeranej časti dát v reálnom čase predstavuje tiež zložitú úlohu [8].
Ukladanie údajov, napríklad v databáze, z pohľadu reálno-časového vyhodnocovania dát je absolútne
vylúčené [20]. Pričasté posielanie záznamov o tokoch ale môže často spôsobiť zníženie výkonnosti
sieťových prenosov, oneskorenie alebo dokonca aj stratu údajov. Z tohto dôvodu, výmena dát medzi
monitorovacím systémom a meracím(mi) bodom(mi) sa bežne vykonáva po väčších časových
úsekoch. Takýmto spôsobom je síce možné zredukovať nežiadané zaťažovanie sieťovej prevádzky,
vyhodnocovanie údajov v reálnom čase sa ale stáva nemožnou. Z toho dôvodu je potrebné určiť
správny pomer medzi intervalmi exportu záznamov o tokoch a efektívnym využitím dostupných
prostriedkov. V prípade často sa meniacej charakteristiky dnešných sietí je to ale bez
automatizovaných procesov priam nemožné.
114
Jakab et al.
7 OVERENIE IDENTIFIKOVANÝCH OTVORENÝCH PROBLÉMOV
Na overenie vybraných problémov, vyskytujúcich sa pri monitorovaní sieťovej prevádzky, bola
realizovaná skupina experimentov. Experimenty sa zameriavali:


na odhad priemerného objemu dát, ktoré sa pri monitorovaní musia spracovať,
určenie priemerného vyťaženia systémových prostriedkov, ktoré v sebe
monitorovanie.
prináša
Cieľom experimentov bolo potvrdenie domnienky, že s rastúcimi parametrami sieťovej infraštruktúry
(čo sa týka priepustnosti a počtu klientov) narastú aj požiadavky kladené na monitorovaciu
a vyhodnocovaciu platformu. Pri overení tejto domnienky bola využitá monitorovacia platforma
BasicMeter (BM) [9], ktorá bola nasadená v prostredí podľa Obrázku 4. Export dátových tokov
prebiehal na základe IPFIX protokolu prostredníctvom BM Exportéra, ktorý prijímal prevádzku
generovanú v sieťovej topológii prostredníctvom zrkadleného portu v topológii.
Na zistenie priemerného objemu dát, ktorý je potrebné pri monitorovaní spracovať a približné
vyťaženie systémových prostriedkov, boli realizované merania v dvoch existujúcich sieťach. Každá
z nich mala rôzne množstvo pripojených koncových zariadení a rýchlosť liniek.
Experimenty boli realizované opakovane. Zo získaných výsledkov boli určené priemerné hodnoty
objemu dát za 1 hodinu. Pri meraniach sa sledovalo aj priemerné vyťaženie smerovača (Cisco 2811,
IOS 12.4T), ktorý sa okrem štandardných smerovacích úloh prostredníctvom protokolu Netflow [3]
podieľal aj na vytváraní a exporte záznamov o tokoch prevádzky. Výsledky sú zhrnuté v Tabuľke 2.
Obr. 4. Meracia topológia.
Sieť 1
Sieť 2
Počet koncových zariadení
11
442
Rýchlosť rozhrania linky
100 Mb/s
1 000 Mb/s
Objem prenesených údajov
210 MB
10 075 MB
Počet prenesených paketov
318 263
16 996 596
Priemerné využitie CPU s vypnutým Netflow
3%
31 %
Priemerné využitie CPU so zapnutým Netflow
6%
48 %
115
Tab. 2. Výsledky experimentov meraní.
Z výsledkov vyplýva, že síce ani jedno z monitorovaní sietí nevyťažovalo linku a systémové
prostriedky na maximum ich výkonnosti, napriek tomu je možné konštatovať, že sieťou bolo
prenesené relatívne veľké množstvo údajov. Navyše, so zvyšovaním rýchlosti liniek, by požiadavky na
systémové prostriedky úmerne rástli. Napríklad pri monitorovaní prevádzky s rýchlosťou liniek 1 Gb/s
by bolo potrebné počas jedného dňa spracovať a vyhodnotiť približne 112 TB údajov. V súčasnosti ale
existujú aj oveľa rýchlejšie spôsoby prenosu dát [13].
Je možné teda konštatovať, že problémy týkajúce sa veľkého objemu dát, ktoré je potrebné počas
monitorovania spracovať a z toho vyplývajúce vyťaženie systémových prostriedkov sú aktuálne.
8 ADAPTÍVNY EXPORT
PREVÁDZKY
INFORMÁCIÍ
O
TOKOCH
SIEŤOVEJ
Pod pojmom optimalizácia monitorovania sieťovej prevádzky sa rozumie návrh a implementácia
takých mechanizmov a metód, ktoré sú adresované na vyriešenie ich nedostatkov. Vzhľadom na
otvorené problémy uvedené v predošlých kapitolách a výsledky experimentov sa má optimalizácia
monitorovania sieťovej prevádzky hlavne zameriavať na:




minimalizáciu celkového preťaženia siete spôsobeného ich monitorovaním,
zvýšenie efektivity využívania a minimalizáciu zaťaženia systémových prostriedkov
monitorovacími mechanizmami,
zvýšenie presnosti vyhodnocovacích mechanizmov,
a maximalizáciu schopnosti vyhodnocovania dát v reálnom čase.
Dosiahnutie týchto cieľov je možné prostredníctvom adaptívneho exportu informácií o tokoch sieťovej
prevádzky, na ktorý v súčasnosti neexistuje žiadna referencia v odbornej a ani vedecko-výskumnej
sfére.
116
Jakab et al.
Využitie systémových prostriedkov monitorovacími mechanizmami je v dôsledku meniaceho sa
charakteru sieťovej prevádzky často neefektívne. Výrazným nedostatkom existujúcich riešení je
absencia adaptívnych exportovacích metód, ktoré by zohľadňovali stav a vlastnosti sieťovej
prevádzky. Konceptuálny návrh adaptívneho exportu informácií o tokoch sieťovej prevádzky
predstavuje:



Prispôsobením určitých parameterov exportu informácií o tokoch k aktuálnemu stavu sieťovej
prevádzky je možné značne prispieť k vyriešeniu vyššie uvedených cieľov optimalizácie.
Takéto vlastnosti predstavujú napríklad objem dát, z ktorých sa vytvárajú záznamy o tokoch
alebo ich čas exportu.
Pri adaptívnom exporte je potrebné stanoviť aj správny pomer medzi intervalmi exportu
a efektívnym využitím dostupných sieťových a systémových prostriedkov. Intervaly exportu
sú dôležité z dôvodu monitorovania sieťovej prevádzky v reálnom čase, ktoré uprednostňujú
čo najmenší časový úsek.
Pre dosiahnutie efektívneho vyhodnotenia dát sa použije viacdimenzionálna analýza rôznych
charakteristík sieťovej prevádzky. Pri takejto analýze, sa namiesto jedinej charakteristiky pri
vyhodnotení aktuálneho stavu sieťovej prevádzky zohľadní viac parametrov. Prostredníctvom
tejto metódy je možné výrazne zredukovať počet nesprávnych úsudkov monitorovacieho
systému, akým je napríklad signalizácia chýb aj v prípade, keď sa v skutočnosti nejedná
o žiadnu hrozbu alebo problém.
V prípade dvoch parametrov, určenie správneho pomeru by mohol byť uskutočnený pomocou
karteziánskej súradnicovej sústavy, kde x-ová os bude predstavovať maximálny objem
prevádzky a y-ová os interval exportu záznamov o tokoch. Príklad takejto sústavy je uvedený
na Obrázku 5.
Každý analyzovaný parameter by bol priradený k jednej osi, nad ktorou by sa vykonávala
zvolená matematicko-štatistická metóda (napríklad štatistické rozdelenie, vzdialenosť od
preddefinovanej hodnoty alebo súboru hodnôt, atď.). Viacdimenzionálna analýza by sa
dosiahla súčasným vykonaním analýz nad týmito parametrami.
117
Obr. 5. Určenie správneho pomeru parametrov adaptívneho exportu.


Kľúčovým faktorom je teda definícia parametrov, ktoré budú jednou zo vstupných hodnôt
metódy adaptívneho exportu. Táto úloha si vyžaduje realizáciu experimentov, ktoré by mali
jednoznačne určiť charakteristiky prevádzky sietí, ktorých zmena výrazne ovplyvní výkonnosť
siete a efektivitu využívania systémových prostriedkov monitorovacími systémami.
Výsledkom má byť dosiahnutie vyššie uvedených cieľov optimalizácie.
Umiestnenie modulu adaptívneho exportu sa navrhuje medzi meracím a exportovacím procesom (viď.
Obrázok 6.) meracieho nástroja BasicMeter [9]. Takto sa dosiahne efektívne vyhodnotenie vyššie
spomenutých vstupných parametrov, na základe ktorých bude export informácií o tokoch sieťovej
prevádzky prispôsobený. Významnú úlohu okrem modulu pre adaptívny export informácií o tokoch
prevádzky budú mať aj ďalšie dva procesy:


Merací proces bude slúžiť na odchytávanie prevádzky a zaraďovanie jednotlivých paketov do
tokov na základe prednastaveného kľúča toku. Tieto toky budú ukladané do zásobníka tokov.
Pre odchytávanie paketov sa použije knižnica libpcap. Tento proces bude zároveň poskytovať
informácie na základe ktorých sa určia vstupné parametre adaptívneho exportu.
Exportovací proces na základe výstupov z modulu pre adaptívny export bude odosielať
zhromažďovaciemu procesu informácie o tokoch s použitím protokolu IPFIX. Tieto údaje
bude získavať zo zásobníka.
Pre dosiahnutie optimalizácie monitorovania sieťovej prevádzky sa v súčasnosti vyžadujú minimálne
dva parametre:
1. Interval pre expiráciu záznamov o tokoch v závislosti od charakteru sieťovej prevádzky
v prípade vyhodnotenia dát v reálnom čase.
2. Maximálny objem spracovanej prevádzky, ktorý neprináša žiadne alebo len akceptovateľné
zaťaženie systémových a sieťových prostriedkov.
118
Jakab et al.
Rozšírenie týchto parametrov o ďalšie faktory sa v budúcnosti nevylučuje.
Obr. 6. Architektúra adaptívneho exportu.
9 ZÁVER
Dôležitým aspektom budovania, spravovania a optimalizácie rozsiahlych a komplexných počítačových
sietí predstavuje meranie ich záťaže a správania sa. Nenahraditeľný prostriedok pre vykonanie tejto
úlohy predstavuje monitorovanie sieťovej prevádzky. Pomocou monitorovania rôznych
prevádzkových vlastností je možné zabezpečiť plynulú funkčnosť aplikácií, ako napríklad hlas cez
internet (VoIP) alebo video na požiadanie (VoD). Okrem zabezpečenia funkčnosti multimediálnych
aplikácií umožňuje aj odhalenie vnútorných a vonkajších útokov, dominantných zdrojov prevádzky
alebo sledovanie, kto s kým komunikoval, ako dlho, pomocou ktorého protokolu. Taktiež umožňuje
poskytovateľom internetových služieb (ISP) zabezpečiť splnenie podmienok uvedených v zmluve
o dohodnutej úrovni poskytovania služby (SLA) a efektívnejšie plánovať budúci rozvoj siete.
Jednotlivé úkony súvisiace s monitorovaním a vyhodnocovaním nameraných hodnôt obklopuje veľa
problémov. Primeraná časť týchto problémov bola za posledné desaťročie úspešne vyriešená.
Vytvorili sa rôzne techniky, metódy a nástroje pre zachytávanie a vyhodnocovanie vlastností dnešných
konvergovaných sietí. Niektoré problémy ale ostávajú naďalej otvorené.
Tento príspevok podáva stručný prehľad o problematike monitorovania sieťovej prevádzky. Uvádza
vlastnosti sietí, ktoré sa pri ich monitorovaní a meraní najčastejšie sledujú, ako aj rôzne prístupy
určovania charakteristík sieťovej prevádzky. Definuje otvorené problémy, ktoré sa pri monitorovaní
vyskytujú, pričom jeho výstupom je konceptuálny návrh adaptívneho exportu informácií o tokoch,
ktorá je adresovaná na optimalizáciu monitorovania sieťovej prevádzky.
119
POĎAKOVANIE
Tento príspevok vznikol vďaka podpore v rámci operačného programu Výskum a vývoj, pre projekt:
Kompetenčné centrum znalostných technológií pre inovácie produkčných systémov v priemysle
a službách, kód ITMS: 26220220155, spolufinancovaný zo zdrojov Európskeho fondu regionálneho
rozvoja.
[1]
CASE, J.D., M. FEDOR, M.L. SCHOFFSTALL a J. DAVIN. INTERNET ENGINEERING
TASK FORCE (IETF). Simple Network Management Protocol (SNMP): Request for
Comments (RFC 1157). 1990. Dostupné z: http://www.ietf.org/rfc/rfc1157.txt
[2]
CHOFFNES, D. R., F. E. BUSTAMANTE a Z. GE. Crowdsourcing service-level network
event monitoring. Proceedings of the ACM SIGCOMM 2010 conference on SIGCOMM SIGCOMM '10. New York, New York, USA: ACM Press, 2010, roč. 40, č. 4, s. 387-398.
DOI: 10.1145/1851182.1851228.
[3]
CLAISE, B. INTERNET ENGINEERING TASK FORCE (IETF). Cisco Systems NetFlow
Services Export Version 9: Request for Comments (RFC 3954). 2004. Dostupné z:
http://www.ietf.org/rfc/rfc3954.txt
[4]
CROVELLA, M. a B. KRISHNAMURTHY. Internet measurement: infrastructure, traffic,
and applications. Hoboken, NJ: Wiley, 2006, xxii, 495 p. ISBN 978-047-0014-615.
[5]
FLOYD, S. a V. PAXSON. Difficulties in simulating the Internet. IEEE/ACM Transactions on
Networking. 2001, vol. 9, issue 4, s. 392-403. DOI: 10.1109/90.944338. Dostupné z:
http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=944338
[6]
GARCIA-DORADO, J., J. HERNANDEZ, J. ARACIL, J. LOPEZ DE VERGARA, F.
MONSERRAT, E. ROBLES a T. DE MIGUEL. On the duration and spatial characteristics of
internet traffic measurement experiments. IEEE Communications Magazine. 2008, vol. 46,
issue 11, s. 148-155. DOI: 10.1109/MCOM.2008.4689258.
[7]
GIERTL, J., Ľ. HUSIVARGA, M. RÉVÉS, A. PEKÁR a P. FECIĽAK. Measurement of
Network Traffic Time Parameters. In: Proceedings of the Eleventh International Conference
on Informatics (INFORMATICS). Košice: TUKE, 2011, s. 33-37. ISBN 978-80-89284-94-8.
DOI: 978-80-89284-94-8.
[8]
JAKAB, F., R. JAKAB, Ľ. KOŠČO a J. GIERTL. Communication Protocol in Computer
Network Performance Parameters Measurement. In: 4th International Information and
Telecommunication Technologies Symposium (I2TS). Florianopolis, Santa Catarian Island,
Brazil: Federal University of Santa Catarina, 2005, s. 161-162. ISBN 858926405X.
[9]
JAKAB, F., Ľ. KOŠČO, M. POTOCKÝ a J. GIERTL. Contribution to QoS Parameters
Measurement: The BasicMeter Project. In: International Conference on Emerging eLearning
Technologies and Applications (ICETA). Košice, Slovakia: elfa, s.r.o., 2005, s. 371-377. ISBN
8080860166.
120
Jakab et al.
[10]
LEE, H.J., M.S. KIM, J.W. HONG a G.H. LEE. QoS Parameters to Network Performance
Metrics Mapping for SLA Monitoring. In: Proceedings of the Korean Network Operations
and Management (KNOM). Korea: Korea University, 2002, s. 42-53.
[11]
PANG, R. Towards Understanding Application Semantics of Network Traffic. Princetown,
USA, 2008. Dizertačná práca. Princetown University.
[12]
QUITTEK, J., T. ZSEBY, B. CLAISE a S. ZANDER. INTERNET ENGINEERING TASK
FORCE (IETF). Requirements for IP Flow Information Export (IPFIX): Request for
Comments (RFC 3917). 2004. Dostupné z: http://www.ietf.org/rfc/rfc3917.txt
[13]
SCHLEPPLE, N., M. NISHIGAKI, H. UEMURA, K. OBARA, H. FURUYAMA, Y.
SUGIZAKI, H. SHIBATA a Y. KOIKE. 4x10 Gb/s High-Speed Link Over Thin GI 50/125
Plastic Optical Fibers and Compact Optical Sub-Assembly. IEEE Photonics Technology
Letters. 2012, vol. 24, issue 19, s. 1670-1672. DOI: 10.1109/LPT.2012.2209636.
[14]
SHAIKH, A., C. ISETT, A. GREENBERG, M. ROUGHAN a J. GOTTLIEB. A case study of
OSPF behavior in a large enterprise network. In: Proceedings of the 2nd ACM SIGCOMM
Workshop on Internet Measurment. New York, NY, USA: ACM, 2002, s. 217-230. DOI:
10.1145/637201.637236.
[15]
SHIMOKAWA, I. a T. TARUI. Network Monitoring Method Based on Self-learning and
Multi-dimensional Analysis. In: The Second International Conference on Advances in
Information Mining and Management (IMMM). Venice, Italy: IARIA, 2012, s. 47-53. ISBN
978-1-61208-227-1. Dostupné z:
http://www.thinkmind.org/download.php?articleid=immm_2012_3_10_20025
[16]
SPRING, N., R. MAHAJAN, D. WETHERALL a T. ANDERSON. Measuring ISP
Topologies With Rocketfuel. IEEE/ACM Transactions on Networking. 2004, vol. 12, issue 1,
s. 2-16. DOI: 10.1109/TNET.2003.822655.
[17]
TANENBAUM, A. S. a D. WETHERALL. Computer networks. 5th ed. Boston: Pearson,
2011, 951 s. International edition. ISBN 978-013-2553-179.
[18]
VOKOROKOS, L., N. ÁDÁM a A. BALÁŽ. Application of intrusion detection systems in
distributed computer systems and dynamic networks. In: Computer Science and Technology
Research Survey (CST). Košice, Slovakia: elfa, s.r.o., 2008, s. 19-24. ISBN 9788080861001.
[19]
VOKOROKOS, L., A. KLEINOVÁ a O. LÁTKA. Network Security on the Intrusion
Detection System Level. In: Proceedings of the IEEE International Conference on Intelligent
Engineering Systems (INES). Budapest, Hungary: Óbuda University, 2006, s. 270-275. DOI:
10.1109/INES.2006.1689382.
[20]
VOKOROKOS, L., A. PEKÁR a N. ÁDÁM. Data preprocessing for efficient evaluation of
network traffic parameters. In: Proceedings of the IEEE 16th International Conference on
Intelligent Engineering Systems (INES). Budapest, Hungary: Óbuda University, 2012, s. 363367. DOI: 10.1109/INES.2012.6249860.
[21]
WALDBUSSER, S., R. COLE, C. KALBFLEISCH a D. ROMASCANU. INTERNET
ENGINEERING TASK FORCE (IETF). Introduction to the Remote Monitoring (RMON)
Family of MIB Modules: Request for Comments (RFC 3577). 2003. Dostupné z:
http://www.ietf.org/rfc/rfc3577.txt
121
[22]
WANG, L., X. ZHAO, D. PEI, R. BUSH, D. MASSEY, A. MANKIN, S. F. WU a L.
ZHANG. Observation and analysis of BGP behavior under stress. In: Proceedings of the 2nd
ACM SIGCOMM Workshop on Internet measurment (IMW). New York, NY, USA: ACM,
2002, s. 183-195. DOI: 10.1145/637201.637231.
[23]
WIMMER, G., R. PALENČÁR a V. WITKOVSKÝ. Stochastické modely merania.
Bratislava: Grafické štúdio Ing. Peter Juriga, 2001, 115 s. ISBN 80-968-4492-X.
[24]
Wireshark: Network protocol analyzer. Wireshark [online]. 2013 [cit. 2013-06-23]. Dostupné
z: http://www.wireshark.org/
[25]
WOLF, T., R. RAMASWAMY, S. BUNGA a Ning YANG. An Architecture for Distributed
Real-Time Passive Network Measurement. In: 14th IEEE International Symposium on
Modeling, Analysis, and Simulation of Computer and Telecommunication Systems
(MASCOTS). Washington, DC, USA: IEEE Computer Society, 2006, 335 - 344. DOI:
10.1109/MASCOTS.2006.11.
[26]
ZSEBY, T., BOSCHI, N. BROWNLEE a B. CLAISE. INTERNET ENGINEERING TASK
FORCE (IETF). IP Flow Information Export (IPFIX) Applicability: Request for Comments
(RFC 5472). 2009. Dostupné z: http://www.ietf.org/rfc/rfc5472.txt
2(1), 2013, 122–124, DOI: 10.18267/j.aip.18
Online: aip.vse.cz
Sekce / Section:
Knižní recenze / Book reviews
Sociální inženýrství aneb umění klamu
Tomáš Klíma1
1
[email protected]
Abstrakt: Recenze knihy Umění klamu od Kevina Mitnicka, která nám
představuje sociální inženýrství jakožto nástroj, který je v současnosti
plnohodnotným doplňkem k technicky založeným prostředkům v arzenálu
narušitelů informační bezpečnosti. Na rozdíl od nich však netrpí tak rychlým
zastaráváním, proto je pohled na jeho základy od jednoho z nejproslulejších
hackerů stále aktuální a má informační hodnotu nejen pro řešitele bezpečnosti, ale
i pro běžné uživatele, kterých se probíraná problematika bezpochyby týká.
Klíčová slova: recenze, sociální inženýrství, sociotechnika, informační bezpečnost
Title: Social engineering or the art of deception
Abstract: Review of the Kevin Mitnick´s book Art of deception. This book
introduces to us the social engineering as complementary tool to technically-based
approaches to penetration of information security of organisations. Unlike these
approaches the social engineering doesn´t become obsolete so fast which means
this book has a value for the IT security guys as well as for the end users who are
the main victims of social engineering.
Keywords: Review, Social engineering, Information security
123
RECENZE KNIHY
MITNICK, Kevin, SIMON, William. Umění klamu. 1. vyd. Gliwice: Helion,
2003. 345 s. ISBN 83-7361-210-6.
Sociální inženýrství neboli sociotechnika je jedním ze způsobů, jak mohou útočníci narušit bezpečnost
organizace bez použití technických nástrojů. Spoléhají přitom na nejslabší článek, v tomto případě na
lidský faktor, který bývá při řešení bezpečnosti často neprávem opomíjen. Jedním z nejúčinnějších
a nejúčelnějších způsobů ochrany je vzdělávání uživatelů a jejich informovanost o metodách, které
útočníci využívají. Přitom ovšem řešitelé bezpečnosti narážejí na problém nedostatku kvalitní
literatury (zejména v českém překladu), která by byla nejen obsahově kvalitní, ale zároveň i čtivá a pro
čtenáře, neznalého IT světa a terminologie, atraktivní.
Monografie Umění klamu od Kevina Mitnicka bezpochyby výše zmíněné požadavky splňuje, navíc je
již jméno autora zárukou, že půjde o fundovaný výklad podložený vlastní praktickou zkušeností (která
nicméně autora přivedla na řadu let do vězení). Na 345 stranách je v šestnácti kapitolách členěných do
čtyř oddílů probráno vše potřebné k pochopení podstaty útoku a obrany proti manipulaci sociálním
inženýrem.
První oddíl se věnuje představení slabin informačních systémů a vysvětluje, jak jsou organizace
pomocí sociotechniky zranitelné. Druhý pak popisuje, jak sociotechnici využívají ochotu a důvěru
uživatelů k poskytnutí požadovaných informací. Vše je demonstrováno na základě "fiktivních
historek". Při bližším zkoumání a zběžné znalosti autorovy další tvorby je ovšem zřejmě, že tyto
historky jsou často založené na skutečných případech, jen identifikační údaje firem a zaměstnanců
jsou z pochopitelných důvodů pozměněny.
V třetím oddíle jsou pak rozvinuty další scénáře, které ukazují možnosti hlubšího průniku do
infrastruktury firmy a odcizení citlivých údajů. Také jsou nastíněny motivy útočníků od prosté pomsty
propuštěného zaměstnance až po kyberterorismus. Čtvrtý oddíl představuje způsoby možné obrany.
Konkrétně se jednotlivé kapitoly tohoto oddílu zaměřují na tvorbu účinného školení a návrh
bezpečnostní politiky organizace1.
V závěru se pak nachází "bezpečnost v kostce", neboli shrnutí klíčových informací formou seznamů
a tabulek. Zvláštní pozornost je vhodné mimo jiné věnovat předmluvě, která v krátkosti shrnuje
autorův (kontroverzní) život a zdůvodňuje jeho odborné směřování. Pokud by ovšem čtenář chtěl
získat o autorovi více informací, je vhodné se obrátit na nezávislé zdroje.
Jazyková úroveň monografie je na slušné úrovni a je třeba vyzdvihnout fakt, že na rozdíl od mnoha
konkurenčních titulů v oblasti bezpečnosti informací, či konkrétně bezpečnosti IT, nedošlo při
překladu ke zmatení termínů, což je ovšem i částečně dáno netechnickou povahou publikace.
1
Šestnáctá kapitola obsahuje vzor bezpečnostní politiky firmy, který je možné upravovat "na míru" konkrétní organizaci.
124
Klíma
Text je vhodně členěn do krátkých podkapitol dle jednotlivých příkladů a scénářů, což usnadňuje čtení
a následně i pochopení. Pokud nepočítáme přílohy, není text doplněn obrázky ani grafy, což lze ovšem
vzhledem k povaze textu omluvit.
Vzhledem k faktu, že autor se knihou obrací zejména na koncové uživatele a na řešitele bezpečnosti
připravující jejich školení, je zvolena odpovídající úroveň odbornosti textu, který je srozumitelný i bez
předchozí znalosti terminologie či teorie bezpečnosti informačních systémů. Osobně bych čekal, že
autor v dalších publikacích půjde hlouběji a zaměří se na detaily konkrétních typů sociotechnických
útoků2. Bohužel tomu tak není a Mitnick dále vesměs zůstáva na povrchu a zkoumání detailů nechává
pak na svých následovnících.
Celkově lze tuto knihu (i další díla autora) doporučit pro seznámí s fenoménem sociálního inženýrství,
zejména s jednotlivými technikami a postupy, které jsou využívány k oklamání koncových uživatelů
a následně k získání patřičných informací (hesla, interní údaje). Pokud s tímto uživatel obeznámen
není, existuje zde velké riziko, že při samotném útoku sociotechnika nejenže poskytne požadované
informace, ale dokonce ani s odstupem času nedokáže identifikovat, že byl oklamán, a incident tak
zůstane nezachycen, což v důsledku znamená, že vyzrazené informace mohou být dále použity
k hlubší úrovni průniku do infrastruktury firmy (např. s využitím technických nástrojů).
Přestože se může zdát, že tento typ útoků se v našich zeměpisných šířkách prakticky nevyskytuje
a spíše než přímého kontaktu s pracovníky se využívá phishingu (včetně jeho „cílené“ podoby spear
phishingu), rozesílání malwaru a dalších technik „hromadného ničení“, opak je pravdou, o čemž
svědčí i fakt, že IT bezpečnostní firmy působící na našem území, jmenovitě ESET3, již do své nabídky
penetračního testování (způsob ověřování bezpečnosti systémů organizace) zařadily i testy ve formě
fingovaného sociálního inženýrství, ať už se jedná o ověřování reakce pracovníků na přímý osobní,
telefonický či mailový kontakt.
Na závěr bych tedy pro ilustraci sofistikovanosti útoků, se kterými se můžeme setkat, použil slova
samotného Mitnicka: „Dobrý sociotechnik plánuje svůj útok jako šachovou partii, předvídá otázky,
které může oběť klást a připravuje si patřičné odpovědi.“ Kniha, kterou jsme si dnes představili, by
nám tedy měla pomoci, aby naše organizace takovou partii lacině neprohrála.
SEZNAM POUŽITÝCH ZDROJŮ
[1]
2
MITNICK, Kevin, SIMON, William. Umění klamu. 1. vyd. Gliwice: Helion, 2003. 345 s.
ISBN 83-7361-210-6.
Dnes je zejména populární využívat sociotechniky ve spojení s phishingem, distribucí malware, a dalšími prostředky, k
čemuž jsou již dostupné i softwarové nástroje - např. modul SET (Social Engineering Toolkit) dostupný v Metasploitu.
Využití tohoto spojení sociotechniky se speciálním softwarem/malwarem stojí za několika významnými datovými úniky z
poslední doby (např. RSA). Tento trend je v krátkosti zmíněn v kapitole 7, odkazy na malware a spyware jsou pak na
několika dalších místech v knize.
3 Viz webová stránka: http://www.eset.cz/cz/firmy/eset-services/bezpecnostni-audit/socialni-inzenyrstvi/
2(1), 2013, 125–131, DOI: 10.18267/j.aip.19
Online: aip.vse.cz
Sekce / Section:
Zamyšlení / Reflections
Relativita poznání jako východisko uvažování
Martin Sova1
1
[email protected]
Abstrakt: Naše neschopnost pochopit hloubkově skutečně každou myšlenku, jež
přijímáme za pravdivou, nás nutí omezit se na povrchní porozumění a odevzdat se
všanc tomu, co je nám prezentováno jako pravdivé ze zdrojů, které jsou
považovány za autoritativní. Příspěvek se zabývá rozborem relativity poznání
světa, neexistencí objektivní pravdy a naznačuje nebezpečí spočívající v
synergickém působení psychických mechanismů jedince a systému, v němž hraje
roli, při jeho snahách o co nejpřesnější deskripci skutečnosti.
Klíčová slova: realita, znalost, dogma, paradigma, víra, systém
Title: Relativity of knowledge as basis of thinking
Abstract: We’re unable to understand the depth of every idea we accept as true.
We’ve to be believed in facts, presented to us as the true from source considered as
authoritative. This paper discusses relativity of knowledge, nonexistence
of objective truth and indicates danger inherent in the synergistic effect
of psychological mechanisms and the system role of human being trying to
objectively describe reality.
Keywords: Reality, Knowledge, Dogma, Paradigm, Belief, System
126
Sova
ZAMYŠLENÍ
1 ÚVOD
Tím, jak usedne jedinec do školních škamen, začíná přijímat fakta, prezentovaná mu jako objektivní
realita, neoddiskutovatelná deskripce světa přesně tak, jak je. Nikoliv tedy, jako současný stav
poznání, respektive výběr ze současného hlavního názorového proudu jednotlivých vědních disciplín,
jak by to mělo být ve skutečnosti. Sama tato fakta jsou holým výřezem z těchto teorií, jejichž podstatu
je schopen pochopit zpravidla jen absolvent vysoké školy spjaté s dotyčným oborem.
Velmi málo lidí nezabývajících se teoretickou fyzikou by pravděpodobně bylo schopno odpovědět na
otázku, proč se domnívá, že svět je tvořen z atomů a jaké má pro to důkazy. Přesto většina
středoškolsky vzdělané západní společnosti by bez váhání odpověděla, že vesmír je z nich vytvořen.
O pravdivosti skutečností, jimž nejsme s to porozumět do hloubky, jsme jednoduše přesvědčeni na
základě toho, že nám daná skutečnost byla řečena. Byla nám sdělena nějakým subjektem, kterému
věříme, ve který máme důvěru. Jedincem akceptovaným z titulu jeho odbornosti anebo jeho
autoritativního postavení, případně jsme ji získali z člověkem vytvořeného informačního zdroje.
Primární zdroj těchto údajů je o mnoho vrstev hlouběji a nejsme mu schopni bez vynaložení
dostatečných časových nákladů na jeho studium porozumět. Víra je zpravidla chápána jako výraz pro
to, kdy uznává jedinec určité náboženské učení, které nelze standardními vědeckými metodami ověřit.
Ve skutečnosti ale věřící jsou všichni lidé (disponující schopností myšlení na určité úrovni) bez
rozdílu. Jistotu o skutečnosti máme jen na určité vrstvě vnímání reality. S růstem složitosti problému
ale jsme nuceni přijímat stále větší objem přímo neověřitelných fakt, v jejichž pravdivost věříme. Ve
skutečnosti každý je věřícím, každý má v mysli vytvořen svůj vlastní obraz světa, poskládaný
z výkladu autorit, jimž uvěřil, že mluví pravdu.
2 VÍRA A KOEXISTENCE VÝKLADŮ REALITY
2.1 NUTNOST EXISTENCE DOGMAT
To, proč existují různé paralelně existující výklady reality, proč v ekonomii stojí proti sobě
keynesiánci a libertiáni, ve fyzice koexistuje několik teorií kandidujících na jednotnou teorii pole (jako
teorie superstrun a smyčková kvantová gravitace), to vše je dáno tím, že při poznávání jakéhokoliv
komplexního problému se objevují výskyty určitých jevů, jež náhled či teorii potvrzují, stejně tak jako
odchylky, jež jí vysvětleny nejsou. Anomálie – paradoxy, které v pozitivním případě vedou k tvorbě
alternativy ke stávajícímu paradigmatu a pokusům o načrtnutí revolučního řešení, které pak po jeho
transformaci v nové paradigma může čelit anomáliím nového druhu. Koexistence názorových směrů
souběžně existujících v témže čase a realitě, a přitom zásadně odlišným způsobem popisujících realitu,
je tedy důsledkem různě provedeného výběru fakt, vytvoření odlišných premis vystavěných na jejich
základě a určení odlišných dogmat. (Dogmatem je chápán pro účely tohoto článku postulát, jehož
pravdivost nelze na stávající úrovni poznání ověřit.) Vzpomeňme zde některé příklady takovýchto
tvrzení, která byla dogmaty v době vzniku teorie, jež se o ně opírala: v ideální ekonomice existuje
127
neviditelná ruka trhu; existuje temná hmota; vesmír vznikl velkým třeskem, atp. Dogma, je-li
postaveno správně, se může na vyšším stupni poznání podařit ověřit a binárně klasifikovat, tj.
jednoznačně ho určit jako pravdu, respektive nepravdu. Například tvrzení jež bylo při ustavení teorie
relativity neověřitelným, tj. že nejvyšší možnou rychlostí pohybu je rychlost světla, je v současnosti již
ve fyzice hlavního proudu pokládáno za ověřený fakt. Pravda je tedy pouze vírou, verifikovanou
vybraným faktem. Model skutečnosti přijímaný jedincem jako pravda se tedy různí v závislosti na
tom, které vjemy ze jsoucen si vybere k verifikaci svého názoru.
2.2 DOPADY EFEKTU MOTÝLÍCH KŘÍDEL
Může jeden chybný předpoklad, jedna chybná informace, data, mít skutečně až tak velký dopad?
Vzpomeňme na zřejmě nejznámější obraz tohoto jevu v literatuře, Ecovo Foucoultovo kyvadlo [5].
Dějová linka v této knize se začíná rozvíjet poté, co dojde k chybné interpretaci jednoho nalezeného
textu. Jeden chybný závěr vede k formulaci teorie opírající se o navzájem se potvrzující důkazy,
k vytvoření nesmírně působivé konstrukce startující procesy i v reálném světě. Ve chvíli, kdy se tento
jeden nápis interpretuje správně, pojivo držící pohromadě tyto důkazy se drolí.
Podobné úkazy se ale vyskytují běžně i v realitě. Filioque, jediné slovo doplněné do latinského textu
Nicejsko-cařihradského vyznání [9], stálo na počátku oddělení východní a západní křesťanské teologie
k souběžnému vývoji dvou, ač na společném základu stojících, zcela odlišných spiritualit, ke
scholastice a papismu na straně jedné a k patristice a učení o nestvořených energiích na straně druhé.
Když se roku 1919 vypravily dvě skupiny britských astronomů, aby pozorovaly ohyb slunečních
paprsků vlivem zemské gravitace a potvrdily tak Einsteinovu teorii relativity, obě ohlásily kladný
výsledek a teorie začala být ve vědecké obci přijímána. Později se však ukázalo, že přesnost tehdejších
měření byla tak nedostatečná, že stěží lze jejich výsledky považovat za průkazné [6]. V roce 2011
proběhl experiment OPERA, během něhož byl zachycen pohyb neutrin nadsvětelnou rychlostí.
Vyvrácením postulátu, že nejvyšší možnou existující rychlostí objektu je c, rychlost světa, byla tedy
považována teorie za vyvrácenou [4]. Tedy do chvíle, než se zjistilo, že měření bylo provedeno
chybně (pravděpodobně kvůli špatně připojenému konektoru) [2]. Epicykly (matematické modely
oběhu těles) sestavované pro geocentrický model byly sestaveny tak přesně, že na jejich základě se
daly velmi přesně předpovídat budoucí polohy nebeských těles [10]. Přesto, že paradigma uspořádání
vesmíru, na jehož základě byly vystavěny, bylo od základu chybné. Do 50. let byly případy
zdravotních komplikací spojených s kouřením všeobecně považovány za ojedinělé komplikace
a obecně napříč lékaři nebyly považovány za nijak zdravotně závadné. Do roku 2005 byly vředy
považovány za následky stresu a konzumace ostrých jídel, dokud Barry Marshall and Robin Warren
nedostali Nobelovu cenu za objevení jejich pravého původce, bakterie Helicobacter pylori [7].
2.3 PSYCHIKA JEDINCE V KONTEXTU SYSTÉMOVÉ TEORIE
Zdá se však, že problém je ještě více vrstevnatým. Průzkumy prokázaly, že při sázkách na koně člověk
v okamžiku, kdy vydá peníze na sázku, začne svému favoritovi věřit násobně více, než mu věřil
o několik málo okamžiků dříve, když se rozhodoval mezi ostatními kandidáty [3]. Ještě jednou si
zmapujme tento případ: existují určitá fakta, tj. historické výsledky koňů, kurz nastavený sázkových
kanceláří. Vnější realita je tedy stále stejná. Okamžikem uskutečnění sázky se ale myšlenkové
pochody začínají stáčet tak, že z objektů jsoucna si mozek vybírá jen ty podněty, jež jsou v souladu
s jeho přesvědčením. Podobně jako při depresi, kdy se začínají spojovat negativní vzpomínky a vjemy
128
Sova
do dokonale ponurého obrazu reality, která ovšem sama o sobě není depresivní, to pouze mozek ji
takto interpretuje. Obdobně zastánce určité teorie logicky tenduje k tomu, vybírat pouze ty případy,
které ji potvrzují a relativizovat ty výskyty určitého jevu, které by tato teorie nevysvětlovala.
Tento mechanismus není od podstaty destrukčním, jak by mohlo se zdát, naopak je v zásadě
ochranným – slouží k tomu, aby člověk mohl poté, co učiní rozhodnutí, napřít síly k jeho realizaci
a myšlení nebylo narušováno zbytečným rozvažováním jiných možných variant. Problémem je, že
s rostoucí komplexitou problému se stává tento mechanismus stále méně užitečným. Nenechme se
mýlit, že řešením je svěřit zpracování dat a pak od nich přejímat matematicky přesné objektivní
výstupy. Ani informatizace a komputerizace zpracování dat nijak není proti tomuto chování imunní,
neboť algoritmus není ničím jiným než dalším typem zápisu představy o světě vytvořené svým
tvůrcem – a zdrojová data, jež zpracovává, jsou výstupem představy jedince, který je získal, o tom,
jaká data a jakým způsobem by se měla získávat.
Pravda, nepravda, dogma a verifikace názorů, to vše jsou jen zdánlivě jakési akademické úvahy
a pojmy bez bezprostřední vazby na praktický život. Opak je pravdou: nic nemá tak přímý dopad na
chování jedince, jeho práci a život jako celek, jako subjektivně vnímaný obraz reality, jako
individuálně vnímaná pravda. Člověk omezen pozorováním okolí přejímá vzory chování a bere je za
vodítko ke své činnosti jako jediné možné. Jak potenciál vrozených či nabytých dovedností tak
fyzických či majetkových dispozic je tak vždy více či méně využíván jen nepatrný zlomek. Procesy
nastavené v mysli opět nijak neusnadňují objektivní náhled na tyto vzory chování a vydělení se kamsi
nad ně, protože mozek je nastaven tak, že stačí přijmout (lhostejno, zda vlastním rozhodnutím či
z donucení, vlivem vnějších tlaků) roli v systému a spustí se automaticky myšlenkové procesy
odpovídající přidělené roli. Vzpomeňme na Zimardův Standfordský experiment, kdy se z psychicky
zdravých studentů, obyčejných lidí vystavených tlaku okolí, stali v závislosti na přidělené role brutální
dozorci, a nebo depresivní pasivní vězni. Mimochodem, experiment se podařilo ukončit díky vydělení
jeho ženy z role manželky ředitele věznice – Zimbardo o takovémto chování mluví jako o chování
"hrdiny," schopného se vydělit z nastaveného chování a myslet i konat nezávisle na tlaku okolností
[11].
Podle systémové teorie každý člen nehledě na jeho bližší charakteristiky vykazuje při působení
stejných podmínek totožné jednání. Z tohoto pohledu je tedy postup hledání a život jedince jako
takový procesem změn chování a myšlení v podobě vyčleňování se a zařazování do jiných případně
vytváření nových systémů, řazení se do nich pod určitou funkcí a fungování v nich. Ovšem i to, že v
některých z nich musí být člověk začleněn je samo o sobě sdílenou znalostí v rámci společnosti, jež
nemusí být zcela pravdivou. Typicky, aktuálně jakoby v západní kultuře byl život jedince jakýmsi
automatizovaným skriptem, v němž může maximálně korigovat průběh záměnou některých
proměnných. Narodí se, jde do školy, pracuje, žena-dítě-hypotéka, vrchol kariéry, krize středního
věku, důchod, smrt.
2.4 MYŠLENÍ VE SVĚTĚ NEURČITOSTI
Uvědomění výše naznačeného působení a tendencí je nutnou, nikoliv však postačující podmínkou pro
identifikaci omezujících vzorců a nastavení postupů vedoucích k jejich vytěsnění. Vodítka pomocná
tomuto snažení se určitým způsobem vymykají z rámce obvyklého vědeckého uvažování – zatímco při
výzkumech je četnost výskytu určitého jevu zpravidla jedním z atributů potvrzení jisté hypotézy,
129
množství jedinců zastávajících určitý názor arbitrem verifikace tohoto názoru naprosto není. Z jiného
úhlu však lze standardní postupy používané v rámci bádání uplatnit bez výhrad – při zkoumání
původních pramenů, zdrojů takovýchto tvrzení.
Obecně je považováno za cosi nepředstavitelného, až heretického, zpochybňovat vědecké poznání
a snažit se o kritický pohled na stav světa předkládaný vědou. Přitom samozřejmě nic jako univerzální
vědecké poznání světa neexistuje – to, co si aktuálně myslíme, že víme, není v zásadě ničím jiným,
než fragmentovaným sumářem pohledů a aktuálně přijímaných teorií (které se mimo to mohou
navzájem vyvracet), vystavěných na podkladu víry v pravost aktuálně známých faktů. Když přijmeme
do určité míry hyperbolizovaný pohledem předkládaný Arbesmanem [1], můžeme konstatovat, že
výrazná část toho, co lidé před sto lety věděli o ekonomii, medicíně nebo psychologii, byly (podle
toho, co víme dnes) naprosto mylné teorie. Jen nedostatečná znalost historie a mechanismu uvažování
nás může vést k přesvědčení, že jsme na tom dnes nějak výrazně lépe a vše, co dnes víme (nejen)
o těchto oborech bude i za dalších sto let při tehdejším stupni poznání stále naprosto přijímáno
a považováno za pravdivé.
Stejnou informaci lze interpretovat různě – v rámci statistického testování hypotéz mohou být při
různě velkém výběrovém vzorku podány různé výsledky pravdivosti hypotéz; obdobně – při zkoumání
obrazových materiálů je vždy zkoumán jejich stav zachycený v čase, nehledě na to, jak průkazná jsou
data, na základě kterých jsou informace utvářeny a interpretovány.
Neexistuje žádná univerzální pravda, která by byla všem dostupná, ale spíše několik polopravd, stejně
tak jako penzum znalostí o každém oboru není nikdy soustředěno do podoby jednotného, ale vždy se
skládá z kompilace vlastních zkušeností, znalostí nabytých studiem psané nebo mluvené řeči. Bohužel
není ve společnosti příliš rozšířena obecná tendence ke kritické interpretaci faktů, málokdo zkoumá
prameny, na základě kterých jsou některé šířené memy, a tak vzniká jakési kulturní povědomí
založené na opakování neověřených faktů.
Ve skutečnosti ovšem zpravidla lidé neznají všechny příčiny svého jednání, zdroje informací jsou
roztříštěny a mají velký rozsah. Nehledě na to, že z každé přijaté informace si jedinec vybírá capta, tj.
pouze to, co ho na základě minulé zkušenosti zajímá, či čemu rozumí, a teprve tento výběr pak
vytváření změnu jeho znalostí. V kontextu fungování tržní ekonomiky i zdánlivě jednoznačná
informace může být interpretována v kontextu minulých zkušeností jedince různě – kupříkladu
numerická hodnota určitého produktu či služby je vždy různými jedinci díky tomu, že jejich představy
získané v minulosti se liší, hodnocena různě – jako nadhodnocený, podhodnocený i přiměřený a pro
uplatnění určitého produktu na trhu je pak klíčové, jak ho vnímá majorita (což by se také dalo
interpretovat tak, že pro konkurenceschopnost produktu je rozhodující, co je považováno za
konsenzuální pravdu, na které se shodne většina zástupců strany poptávky). Inovace a vstup nových
konkurenčních technik mohou být chápány jako metody snažící se tento stav narušit a změnit
zaběhnutá paradigmata buď nabídnutím nových možností k rozhodování při výběru statku, který chce
poptávající směnit za peníze, případně nových informací a nástrojů k jejich získání (ostatně podle
Schumpetera [8] jsou právě inovace hnací silou vlnění ekonomického cyklu) – ať už inovace vzniká
jako chování adaptivní (tj. takové, kdy se přizpůsobují entity novému statu quo), anebo proaktivní
(kdy dochází k aktivnímu vytváření nových postupů či nástrojů bez přímé příčiny z vnějšího
prostředí).
130
Sova
3 ZÁVĚR
Veškeré poznání je relativní a jediným východiskem z tohoto chaosu neurčitosti je selekce bodů jimž
přisoudíme absolutní důvěru, dogmat, od kterých se může odrazit dále a na nichž můžeme stavět
složitější konstrukce. Obdobně jako sázkař zadává svou představu o tom, jaká padnou čísla vybráním
některých čísel na tiketu, vybíráme si z nabídky existujících vysvětlení reality některá a na jejich
základě uzavíráme „sázku,“ tj. snažíme se s nimi operovat. Podobně jako se správnost výběru čísel na
tiketu ověří až v dalším kole losování, jejich platnost se podaří ověřit až na vyšším stupni poznání
dané disciplíny. To, že si zastánci jiných názorových proudů či doktrín vybrali jiné, tedy není nutně
jejich chybou, ale je to jednoduše dáno odlišným výběrem těchto základních „pravd,“ na základě
odlišných myšlenkových postupů a skutečná podstata je autonomně existujícím stavem, vyskytujícím
se nezávisle na jeho deskripci.
SEZNAM POUŽITÝCH ZDROJŮ
[1]
ARBESMAN, Samuel. The half-life of facts: why everything we know has an expiration date.
New York: Penguin Group, 2012, viii, 242 s. ISBN 978-159-1844-723.
[2]
ANTONELLO, M. et al. Precision measurement of the neutrino velocity with the ICARUS
detector in the CNGS beam. Journal of High Energy Physics. 2012, roč. 2012, č. 11, s. -. ISSN
1029-8479. DOI: 10.1007/JHEP11(2012)049.
[3]
CIALDINI, Robert B. Zbraně vlivu: manipulativní techniky a jak se jim bránit. Vyd. 1. V
Brně: Jan Melvil, 2012. Žádná velká věda. ISBN 978-80-87270-32-5.
[4]
COLLABORATON, Opera, et al. Measurement of the neutrino velocity with the OPERA
detector in the CNGS beam. 2011.
[5]
ECO, Umberto. Foucaultovo kyvadlo. V českém klubu vyd. 3. Praha: Český klub, 2009, 566 s.
ISBN 978-808-6922-270.
[6]
KING, D a Michael WERTHEIMER. Max Wertheimer. New Brunswick: Transaction
Publishers, c2005, s. 122-123. ISBN 0-7658-0258-9.
[7]
Press Release: The 2005 Nobel Prize in Physiology or Medicine. In: Nobelprize.org [online].
2005 [cit. 2013-03-31]. Dostupné z:
http://www.nobelprize.org/nobel_prizes/medicine/laureates/2005/press.html
[8]
SCHUMPETER, Joseph A. The theory of economic development: An inquiry into profits,
capital, credit, interest, and the business cycle. University of Illinois at Urbana-Champaign's
Academy for Entrepreneurial Leadership Historical Research Reference in Entrepreneurship,
1934.
[9]
SIECIENSKI, A. The filioque: history of a doctrinal controversy. New York: Oxford
University Press, 2010, ix, 355 s. ISBN 01-953-7204-2.
[10]
VAN DER WAERDEN, B. L. The earliest form of the epicycle theory. Journal for the History
of Astronomy, 1974, 5: 175.
[11]
131
ZIMBARDO, Philip G. The Lucifer effect: understanding how good people turn evil. 2008
Random House trade pbk. ed. New York: Random House Trade Paperbacks, 2008, xx, 551 p.
ISBN 978-081-2974-447.
ISSN: 1805-4951
Články v časopise podléhají licenci Creative Commons Uveďte autora 3.0
This work is licensed under a Creative Commons Attribution 3.0 License

Recenzovaný vědecký časopis / Peer

Transkript

Podobné dokumenty

Sborník příspěvků

ITA_01_2014cover:Sestava 1

Sestava 1 - Aktuálne

rocnikovy_projekt_pe..

University of Economics, Prague

Recenzovaný vědecký časopis / Peer

Untitled - Creative connections

1 ISSN: 1805-4951 - Acta Informatica Pragensia

(se) zde učit… - Skupina Ridera

Seminář o eHealth v Poslanecké sněmovně

PSR-S750 - Hudební nástroje Fila

1/2 Dodatek ke smlouvě JDLink týkající se služby John Deere

Yamaha PSR-S670

HiPath otevřená komunikace

10. číslo Informačního zpravodaje JIB (Zima 2010

Ochrana počítačových sítí na bázi stacionárních a

Program mezinárodní konference MEDTEL ČNFeH 2008 eHealth

zde - LBMS

Co když zavirování telefonu není nejhorší věc, která se

IDS/IPS - ano či ne?