Erinevus lehekülje "Thesis:APL design and implementation" redaktsioonide vahel

@@ 1. rida: / 1. rida: @@
-Back [[Aleksandr_Lenin_MSc_Thesis_topics|to the list of topics]].
-Every model is some sort of an approximation of the real life processes with certain degree of precision. Reality is modelled only to a certain extent, sufficient for the analysis. Attack and threat landscapes are so diverse and dynamic in their nature, so in order to avoid the necessity ''to model the entire world'' we need to draw a line somewhere and keep a certain level of abstraction in our models.
-An example of such a case is attack generation. We may describe a security scenario in our models, but the attack generation procedure still will be complete only with respect to the model -- namely, it will be able to capture these attack vectors only, which ''exist in the model'' and will not be able to take into account factors not captured in the model. But sometimes for analysis we need to go beyond this limitation to enable more thorough analysis, and still do not want to increase the level of model granularity, as it will have certain concequences on the performance and time required to run the analysis, possibly making the entire analysis process inefficient and not suitable to be applied to analyze real-life scenarios.
-Every model has ''incomplete knowledge'' about the environment, world, the context certain processes are modelled and it needs to get this information from some outside libraries containing domain knowledge and acting as a ''knowledge base''.
-For instance, lets consider the case when the attack generator has come up with an attack vector ''clone a credit card'' and additional knowledge is available from the model, that the considered baking card has a magnet stripe on it and is not a chipcard. The attack generation stops at this point, because the model knows nothing about how to clone a card, but the analysis requires more detailed specification of the process. Such information, or, in other words, domain knowledge, may be aggregated in shared libraries - in this particular case, that would be the ''attack pattern library'', or ''APL''. It could contain the scenario "how to clone a magnet card" describing the relevant steps to do it: 1) obtain a skimmer 2) skim a card 3) get an empty card 4) white the memory dump to an empty card. APL would process initially generated attack vectors and "increase" the level of granularity by populating the automatically generated attack scenario with domain knowledge from the library.
-A library can be seen as a knowledge base, and as a library re-usable components (attack patterns). Here we may thik of designing a collaborative environment for the domain knowledge experts to contribute to the library. The library need to be properly designed to facilitate this sort of collaboration. Security and privacy issues must be addressed designing sharing schemes, as attack patterns are very sensitive information for enterprises and needs to be protected when being stored or being transmitted over communicational channels, etc.
-Still, these re-usable components are meant for sharing purposes -- we might think of various ways of sharing:
-* inter-organizational sharing (attack patterns are shared between departments of the same organization in the same security perimiter)
-* cross-organizational sharing (some general attack patterns are shared with competitors and partners for the sake of overall wellfare and in order not to re-invent the wheel)
-* cross-border sharing (sharing attack patterns between enterprises or departments of the same enterprise, residing in different coutries). Here some legal issues come into play, as various countries have different sets of laws and regulations on how sensitive data must be transmitted, treated, processed, stored, etc.
-* publication -- a specific way of sharing patterns with the rest of the world. These patterns have public access and everyone can access and use them. Here some privacy issues might arise and we should think on proper ways to do data ''anonymisation'' before sharing. Privacy issues might arise in the case of other types of sharing as well.
-Eventually, we need to design a prototype of such a library and populate the ''knowledge base'' with initial domain knowledge w.r.t. the project case studies.
-The tasks in this thesis include the following:
-* Write down all the cases when the use of ''APL'' is justified (w.r.t the project case studies)
-* Outline ''what'' should the ''APL'' contain in these cases.
-* Design the initial structure of the ''APL''.
-* Create a prototype.

Erinevus lehekülje "Thesis:APL design and implementation" redaktsioonide vahel

Viimane redaktsioon: 19. veebruar 2020, kell 09:26

Navigeerimismenüü

Otsing