Wyniki wyszukiwania - BazTech

1

A language for security issues specification during the IT security development process

Białas A.

Theoretical and Applied Informatics

|

2008

|

Vol. 20, No. 2

125-145

EN

The paper deals with the modelling of IT (Information Technology) security development process to be compliant with the Common Criteria (ISO/IEC 15408) family of standards. The paper concerns a more extensive project of the IT security development framework (ITSDF) but special attention is paid to improving and extending the means used to build the IT security specification. A dedicated language is proposed to define specification means for development stages other than the security requirement elaboration stage for which the standard does not provide specification means. The proposed means, called “enhanced generics”, can be used to specify items for the security environment, objectives, environmental requirements and the security functions. The enhanced generics have similar features as the components of the security requirements. They have a well defined structure and allow operations (iteration) on themselves. This solution, instead of the informal textual descriptors, ensures better preciseness of the security features description. The key element of the paper is the formal grammar of generics. It allows to derive all possible “legal” enhanced generics. They have semiformal character and features, similarly to the functional and assurance components defined by the standard to specify the security requirements. The paper, concluding an earlier informal approach, introduces syntax and semantics definitions based on the formal grammar and approach used to define the OCL language formally. The proposed means make security specifications more precise and coherent, allowing to reach the assurance level more easily. Moreover, this approach allows to create an IT security development tool in which the specification means are implemented as the design library elements.

PL

Artykuł dotyczy wybranych zagadnień modelowania procesu konstruowania produktów lub systemów teleinformatycznych zawierających elementy zabezpieczeń, zgodnie z wymaganiami określonymi we “Wspólnych kryteriach oceny zabezpieczeń teleinformatycznych” (ISO/IEC 15408) i w standardach z nim związanych. Dotyczy on szerzej zakrojonych prac autora nad szkieletowym systemem konstruowania zabezpieczeń (ITSDF – IT security development framework). Skupiono w nim uwagę na udoskonaleniu i rozszerzeniu środków do tworzenia specyfikacji modeli bezpieczeństwa produktów lub systemów teleinformatycznych. Zaproponowano dedykowany język do specyfikowania własności bezpieczeństwa dla wszystkich etapów konstruowania, innych niż etap definiowania wymagań bezpieczeństwa. Należy nadmienić, że w standardzie Wspólne kryteria tylko dla tego etapu określono środki specyfikacji, czyli komponenty funkcjonalne i uzasadniające zaufanie. Natomiast dla etapów wypracowania: otoczenia zabezpieczeń (“problemu bezpieczeństwa” według wersji 3.1 standardu), celów zabezpieczeń, wymagań dla środowiska eksploatacji oraz funkcji zabezpieczających, dotychczas takich środków nie zdefiniowano. Konstruktorzy zabezpieczeń stosują więc opisy słowne lub zwięzłe, ale dość swobodnie zdefiniowane, sformułowania oznaczane etykietami, które zwane są potocznie generykami. Autor w swej publikacji zaproponował udoskonalenie tego sposobu opisu. Zaproponowane w publikacji środki specyfikacji, z racji swych możliwości, nazwano “udoskonalonymi generykami” (enhanced generics). Są one przeznaczone dla tych etapów konstruowania, dla których dotychczas było brak środków opisu. Podobnie jak zdefiniowane przez standard komponenty wymagań bezpieczeństwa – funkcjonalne oraz uzasadniające zaufanie, wspomniane udoskonalone generyki mają charakter półformalny. Udoskonalone generyki dorównują precyzją i możliwościami komponentom zdefiniowanym w standardzie i razem z tymi komponentami stanowią spójny zbiór środków specyfikacji dla wszystkich etapów konstruowania zabezpieczeń. Mogą posiadać parametry, pod które można podstawiać inne generyki. Pozwala to na iterację, czyli wielokrotne umieszczanie danego generyka w specyfikacji, ale z różnymi podstawionymi wartościami parametrów, np. tego samego zagrożenia z różnymi agentami zagrożenia i atakowanymi zasobami (Przykład 3). Na wzór uszczegółowienia (ang. refinement) komponentu wprowadzono operację uszczegółowienia generyka. Nowum stanowi możliwość wyprowadzania z danego generyka generyków pochodnych (ang. derived), a przede wszystkim predefiniowane ciągi generyków wspomagające rozwiązywania problemów bezpieczeństwa przez konstruktora (ang. supporting chains). Dla danego zagrożenia (reguły polityki bezpieczeństwa czy założenia) przypisano bowiem typowe dla niego cele bezpieczeństwa, które dany problem rozwiązuja˛. Z kolei każdy cel ma przypisane typowe komponenty funkcjonalne, które go wyrażają “w języku wspólnych kryteriów”, zaś pogrupowane komponenty mają przypisane typowe funkcje bezpieczeństwa, które należy zaimplementować w produkcie lub systemie informatycznym. Konstruktor zabezpieczeń, bazując na “typowych”, predefiniowanych rozwiązaniach ma znacznie ułatwioną pracę podczas tworzenia i uzasadniania zadania zabezpieczeń (ang. ST- Security target) lub profilu zabezpieczeń (ang. PP- Protection Profile). Na tle stosowanych dotychczas nieformalnych środków specyfikacji (sformułowań tekstowych, prostych generyków), artykuł pokazuje ich ewolucję do postaci “udoskonalonych generyków”. Pierwszym krokiem była próba określenia stosowanego, lecz nigdzie jeszcze nie zdefiniowanego pojęcia “generyk” (Definicja 1). Następnie podano definicję udoskonalonego generyka, stosując popularną wśród użytkowników standardu notację z kropką (Definicja 2). Stało się to podstawą zdefiniowania składni (Definicja 3) i samego języka (Definicja 4). W ten sposób określono wszystkie możliwe nazwy generyków, nie precyzując jednak ich znaczenia. W celu zdefiniowania semantyki (sekcja 4) posłużono się metodą z rozprawy doktorskiej Richtersa, za pomocą której zdefiniowano semantykę języka OCL (Object Constraint Language), wykorzystywanego do precyzyjnego modelowania w UML (Unified Modeling Language). Istota metody tkwi w przypisaniu interpretacji do stosowanych literałów. W tym sensie środki specyfikacji własności bezpieczeństwa stały się zgodne z językiem OCL i mogą być traktowane jako jego podzbiór. Szerzej te zagadnienia prezentuje monografia [5]. Opisany powyżej zbiór środków do specyfikowania, obejmujący udoskonalone generyki oraz zdefiniowane przez standard komponenty, dzięki zastosowanym formalizmom, pozwala na większą spójność i dokładność modeli oraz na implementacje˛ programowa˛w postaci elementów bibliotecznych systemów wspomagania konstruowania zabezpieczeń teleinformatycznych.

2

On the support UML diagrams understanding during the software maintenance

Kotulski L., Basiura A.

Computer Methods in Materials Science

|

2007

|

Vol. 7, No. 3

366-375

EN

NOTE It was previously reviewed as :On the support image understanding during the software maintenance. Abstract. UML diagrams are generally accepted technique of supporting computing modeling and maintenance systems that are independent from the domain supported by the created system. Final model describes the system with help of object oriented techniques such as class inheritance, packages or the final software deployment diagrams. The mentioned techniques introduce some hierarchy of the developed concepts. An UML model describing all aspects of a system is hard to fully visualized. Usually they contain thousands of elements and relations which are difficult to present in form that can be easy to understand. Unfortunately, we are not able to represent such structures with help of the 2-dimensions manner (monitor screens or paper sheets) so we present only some "flat" aspects of these structures; it is desirable that we should be able move from one "flat" visualization of the hierarchical structure to another one. In this paper, we formalize the term "a flat visualization of the hierarchical graph", and specify the synthesis and analysis operations, that allow us to move between different flat forms. Practical aspect of this proposition is discussed for UML deployment and class diagrams.

PL

Diagramy UML są powszechnie stosowaną techniką wspomagającą modelowanie systemów obiektowych; stają się również wysoce użyteczne podczas modyfikacji systemu spowodowanej zmianami wymagań użytkowników. Pełny model systemu ilustruje jednak wielowymiarowe relacje pomiędzy setkami (tysiącami) składników, często opisywanych w różnych kontekstach (typach diagramów) i poziomach szczegółowości. Takie nasycenie elementów i relacji pomiędzy nimi powoduje bardzo często że model systemu przekracza możliwości percepcyjne człowieka i często jest on pomijany podczas procesu rozwoju. W artykule podejmujemy próbę czytelnego przedstawienia tych powiązań na dwuwymiarowym ekranie komputera. Proponujemy wyświetlanie informacji przedstawiającą tylko jedną perspektywę (tzw. płaską wizualizację grafu) zawierającą przefiltrowany zbiór informacji dotyczących danej części systemu (logicznej lub fizycznej). Udostępniamy użytkownikowi możliwość iteratywnej zmiany tej prospektywny na inną, która z nią jest powiązana. Proces ten opieramy na bazie grafów hierarchicznych, podajemy formalną specyfikację pojęcia płaskiej wizualizacji grafu, oraz definiujemy operacje analizy i syntezy pozwalające zmienić analizowaną perspektywę na inną bardziej (mniej) szczegółową. Wykorzystanie wprowadzonego aparatu formalnego, przedstawione jest na przykładzie analizy diagramów klas i diagramów wdrożenia.

3

Specification of security environment of IT security-related products according to Common Criteria

Białas A.

Theoretical and Applied Informatics

|

2006

|

Vol. 18, nr 2

141-157

EN

The paper concerns IT security development and evaluation processes according to the Common Criteria - CC (ISO/IEC 15408) family of standards, and is based on the results of the author's earlier works dealing with modelling of these processes. The paper focuses on the workout of the security environment specification based on the previously identified features of an IT security-related product, presented in [2]. The security environment presents the nature and scope of the IT security-related product and discusses the threats, policy rules and assumptions of the product working environment. This specification is used for the security objectives definition, which is the basis for further IT security development stages. The UML-based approach was introduced to specify the security environment using predefmed generics contained within the design library. It is part of the common development framework and a computer-aided tool developed on the framework. Using the UML in the Common Criteria based IT security development process allows achieving morę consistent designs in an easier way.

PL

Artykuł dotyczy zagadnień projektowania i oceny bezpieczeństwa produktów teleinformatycznych zawierających elementy zabezpieczeń, zgodnie z wymaganiami określonymi we Wspólnych kryteriach oceny zabezpieczeń teleinformatycznych (ISO/IEC 15408) i w standardach z nimi związanych. Wykorzystując wyniki wcześniejszych prac autora, dotyczących formalizacji i modelowania procesu projektowania zabezpieczeń oraz opracowania środków (pewnego rodzaju języka) do tworzenia specyfikacji projektowych, w artykule skupiono uwagę na sposobie wypracowania specyfikacji otoczenia zabezpieczeń na podstawie określonej wcześniej charakterystyki produktu teleinformatycznego (urządzenia, programu, oprogramowania układowego, systemu). W tym sensie artykuł stanowi bezpośrednią kontynuację rozważań zawartych w pracy [2]. Specyfikacja otoczenia zabezpieczeń wyraża potrzeby odnoszące się do zapewnienia bezpieczeństwa produktu. Zawiera założenia dotyczące środowiska jego funkcjonowania, występujące w nim zagrożenia oraz sformalizowane reguły polityki bezpieczeństwa, których należy przestrzegać podczas jego użytkowania. Specyfikacja ta pozwala na zdefiniowanie celów zabezpieczeń, które są transformowane na wymagania, a potem na funkcje zabezpieczające (nie dyskutowane w artykule). W celu poprawy efektywności procesu projektowania oraz zapewnienia możliwości budowy komputerowego narzędzia wspomagającego, zastosowano język modelowania UML oraz zbiór tak zwanych generyków, opisujących elementarne zagadnienia bezpieczeństwa, stanowiący uzupełnienie, jako środka specyfikacji, komponentów zawartych w standardzie Wspólne kryteria.

4

Identyfying the features of the IT security-related products for the IT development process according to Common Criteria

Białas A.

Archiwum Informatyki Teoretycznej i Stosowanej

|

2005

|

T. 17, z. 1

3-18

EN

The paper deals IT security development and evaluation according to the Common Criteria (ISO/IEC 15408) family of standards. The development process was shown concisely, focusing on its initial stage - preparing precise IT security-related products features specification, influencing other design stages. The UML-based approach was introduced to specify product functionality provided for users and product security features in the same way. It allows to define the common development framework and computer-aided tool. The development process was shown on the "Security Target Introduction" example. Starting from use cases, identifying basic needs of users, to the expression of the structural and behavioral aspects - the whole capturing process was discussed. Elaborating " Security Target Introduction" allows to start next stage, specifying IT security environment, expressing security needs and concerns - not discussed in this paper.

PL

Artykuł dotyczy wybranych aspektów projektowania produktów lub systemów zawierających elementy zabezpieczeń, według zasad zidentyfikowanych przez Wspólne kryteria oceny zabezpieczeń teleinformatycznych (ISO.IEC 15408) I standardy z nimi związane. Zwięźle przedstawiono etapy projektowania. Szczególną uwagę zwrócono na etap wstępny - określenie cech produktu w postaci sformalizowanego "Wprowadzenie do Zadania Zabezpieczeń" , na podstawie którego sukcesywnie wypracowane mogą być kolejne (nie przedstawiana w artykule) specyfikacje projektowe: otoczenia zabezpieczeń, celów zabezpieczeń, wymagań na zabezpieczenia, funkcji zabezpieczających - każda z nich wymagająca precyzyjnego uzasadnienia. Artykuł przedstawia koncepcję wykorzystania języka modelowania UML do wstępnego etapu procesu projektowania, to znaczy do opracowania "Wprowadzenia do Zadania Zabezpieczeń". Pokazano, w jaki sposób zidentyfikować elementy produktu lub systemu istotne z punktu widzenia bezpieczeństwa teleinformatycznego, jak korzystać z przypadków użycia oraz jak doprowadzić do zdefiniowania kooperacji przedstawiającej produkt, jego zachowanie i strukturę. Identyfikacja tych elementów umożliwia zdefiniowanie otoczenia zabezpieczeń - przedstawienia zagrożeń dla produktu lub systemu, zasad polityki bezpieczeństwa, założeń dotyczących stosowania produktu oraz koniecznych do spełnienia przez jego otoczenie.

5

Derivation of Markov processes from the UML statecharts

Babczyński T., Huzar Z., Magot J.

Archiwum Informatyki Teoretycznej i Stosowanej

|

2000

|

T. 12, z. 3

143-171

EN

Statecharts are widely used in system modelling and specification. They might also be used for performance analysis at early stages of system developing. In order to find performance metrices analytically, it is often assumed that models possess Markovian properties. The paper introduces a notion of Markovian statecharts that enables analytical evaluation of system performance. Our Markovian statecharts are driven by UML statecharts. The Markovian statecharts can model delays caused by: activities, which may be performed within system's states, activities initiated during passing between states. We define semantics of Markovian statecharts following an algebraic approach based on the Statecharts Process Algebra. Next, we present how Markovian processes ca be derived from Markovian statecharts.

PL

Mapy stanów stosuje się powszechnie w specyfikacji i modelowaniu systemów informatycznych. Można je wykorzystywać we wczesnych fazach tworzenia systemów do analizy ich wydajności. Często, w celu analitycznego wyliczania metryk wydajnościowych, zakłada się, że badany model posiada markowowskie własności. Artykuł wprowadza pojęcie markowowskich map stanów wzorowanych na mapach stanów z języka UML (United Modelling Language). Wprowadzone Markowowskie mapy stanów modelują dwa mechanizmy map stanów UML: opóźnienia powodowane przez aktywności wykonywane w czasie przebywania w stanie oraz opóźnienia powodowane przez aktywności inicjowane podczas przechodzenia pomiędzy stanami. W pierwszej części, w oparciu o algebrę procesów, artykuł przedstawia formalną operacyjną semantykę markowowskich map stanów. W drugiej części artykuł przedstawia transformację markowowskich map stanów procesy Markova.