AN EFFICIENTSECURE SOFTWARE DEVELOPMENT

FRAMEWORK

CONTENT

THE TOOLSET:OSGI & THE EVERIT FRAMEWORK Cleaner the code - healthier the software Decreasing complexity - fail proof operation Streamlined development - bulletproof application

THE METHODOLOGY Design Analysis, precautions Processes under control Shorteriteration,fewerbugfixes Authenticity and undeniability Awareness, vigilance Corresponding partnership

1

Before we start to introduce our solution, let’s clarify what we mean when we are talking about secure software develop-ment.

In our opinion, this means to keep our eyes on certain se-curity requirements during the whole development project., which also means that we actually do have some security requirements.

On the other hand, we have to consider these requirements also when we choose our toolset, and later during the utili-zation of these tools.

In short, it is all about the proper tool used in a suitable way.

SECURE SOFTWARE DEVELOPMENTTHE EVERIT WAY

2

In our case the chosen tool is the EverIT framework, built on the Java OSGi platform.

Even the Java language, or the OSGi platform itself could be the subject of a security analysis, but this is not what we are aiming for here.

We would like to focus on our own experiences, which were collected during our security sensitive projects. Namely the OSGi platform itself can not be called secure, but it provides many possibilities, through which an OSGi based product can be made secure.

The complete list of the advantages of the OSGi platform will not be listed here either, as it can be reached under the OSGi Alliance site.

The following parts of this document will guide you through the essence of our experiences.

THE TOOLSETOSGI & THE EVERIT FRAMEWORK

3

In recent years we have had a few projects, where the initial Java EE platform was changed to OSGi during the implementation phase, and we had very impressive re-sults each time.

In these projects our lead developers experienced that the modular architecture helped us produce cleaner code, thanks to the conventions of OSGi. So during the process of code reviews it was much easier to notice the details (placed by accident or even on purpose) which could cause vulnerability.

This could be complemented by a proper checkstyle policy and awell configured CI (continuous integration)system, but this is rather to do with the cut back on the overloadwhichtypicallyaffectsourleaddevelopers.

Soaltogetheritisbeneficial,becausewiththesetoolsabetter code coverage is available during the reviews and eventhereviewcanbedeeperandmoreeffective.Nottomention that the system administrators get a more easi-lymaintainableapplication,sothefiltrationofamalwareactivityoranoxiouscode-snippetcouldbemoreefficient.

CLEANER THE CODEHEALTHIER THE SOFTWARE

4

According to our benchmark results, using the OSGi technology and our self-developed framework, we could reach one, and in some cases even two magnitude better response time compared to a traditional Java EE applica-tion. So the system’s load bearing capacity can be higher, and that is how they can be considered more protected against dos and ddos attacks.

Of course there is no system (not even based on OSGi) whichcannotbeflooded,butwithamodular,OSGiap-plication this threshold is higher, assuming the same amount of resource on the attacker side.

On one hand, we could force the attackers to make some extra effort,whichwill make the target (our software orsystem) less tempting. On the other hand, we can gain some time for other defense mechanisms to start before the attackers reach their goal.

Similarly, but on the failover side, a lightweight OSGi ap-plication with quicker booting process brings some extra confidencefortheadministratorscomparedtoamono-lithic, complex system. This factor could be mission criti-cal in case of a service with high availability and SLA.

Furthermore, according to Amdahl’s law, the speedup of a given problem’s solution by parallelization is only pos-sibleuptoacertainpoint,sothebenefitsofOSGiwillnotdisappear even if the availability of resources is relatively high.

So in this case we can state that simplicity meanssecurity.

DECREASING COMPLEXITYFAIL-PROOF OPERATION

5

Many years of continuous research and endeavour to-ward perfection led us so far, that we are not willing to compromise in certain cases. One such example is tech-nologies we use to ease and support development.

Our experience shows that in this case less is often more. Themoresupportorpredefinedcomfortserviceyougetfrom a tool or technology, the higher is the risk that you will find yourself in a tight dependency, and you couldlose your competitive advantage very quickly if a critical bug emerges (and it will with a good chance).

Probably every developer knows the helpless feeling, when a bug turns up in a third party code, out of his au-thority, and the application gets into a vulnerable state (andstaysforawhile)withoutanythingwecandotofinda solution.

The less dependency from various technologies we have, the less exposed state we are in. This is what we believe in, and we try to use our self-developed framework in ev-ery possible case.

STREAMLINED DEVELOPMENTBULLETPROOF APPLICATION

6

If we can not avoid taking an external dependency into our technology stack, it has to be a subject of an inspec-tion, just as accurate as if it were our own development. In this area we require the very same QA rules we do in case of internal development.

As a result, many modules have been created under our framework, which are functionally equivalent to oth-er (well-known) competitors on the market, but to keep things under control can be priceless in certain cases. That (and of course the availability of customization) is why it is worth to make our own implementation of these elements.

This is how we created our own OSGi based authorization and authentication (and many others) components in or-der to leave the Spring Framework.

However the framework does not give a 100% coverage to all technologies and not every technology was written in an OSGi approach, so sometimes they can not be used in an OSGi environment. Therefore, when we receive a requestwecannotfulfillwithourexistingsolutions,wehavetocountwithsomeadditionaleffort,financiallyandin time also.

But at the end these effortswill result in better quality,andlateritcanhelpsavesomebugfixandsomesleep-less nights for the team.

STREAMLINED DEVELOPMENTBULLETPROOF APPLICATION

7

The tools described in the previous chapter are worth nothing if we do not use them in a suitable way, or if we make mistakes during the system design.

That is why the methodology is so important from the se-curity point of view, maybe even more important than the tools themselves.

Realizing this relevance we have introduced some proce-dures which help us produce a higher quality and more secure software.

In some cases these are expanded to the whole organisa-tion, otherwise they are built in the development process.

The origin of these procedures are the Common Criteria (CC) and the Agile/Scrum methodology, which two prin-ciples we managed to merge into our own hybrid project management technique in order to create custom soft-ware solutions with particular security regulations.

The following chapters present a number of practical fea-tures of this technique.

THE METHODOLOGY

8

The base of every development is a precise design, supported by a consistent technique, which also in-cludes a suitable toolset.

At the design stage our choice was UML and Enterprise Architect, and we try to exploit the advantages of this versatile tool.

However, we pay meticulous attention not to immerse in the design in such depth, which would obstruct the lean approach of the product development and the ag-ile organization of work.

DESIGN

9

When developing web-based applications, we bring the OWASP list into sharp focus in the testing phase.

However, it is also necessary to examine the possible vulnerability factors and hypothetical attack forms al-ready in the design phase.

This allows us to build in the requisite controls and de-velop an application which will not fail later on the pen-etration tests.

ANALYSIS & PRECAUTIONS

10

From the design cycle, through the implementation, testing and release sub-processes, we handle the mat-ter of traceability with top priority. We believe we found the perfect toolset to support this pursuit: Git for version control, and Jira for project and process management.

Another key component of secure services or the se-cure software development is the existence of the con-venient staging process and the necessary staging en-vironment.

The permission and access control management, in-stalled already at the beginning of a project, is also part of the practice. We managed to create without compro-mise nearly perfect conditions for this purpose, with the help of our self-operated server infrastructure.

11

PROCESSESUNDER CONTROL

We noticed at EverIT (and also at some partners where we work with the same methods) that Agile (e.g. Scrum) and Lean concepts help us bring down the product de-velopment costs and allows us to access the targeted market quicker.

Beside this very important (but from a security point of view not so relevant) aspect, we had another exciting realization: Thanks to the more frequent version up-grades, the smaller release packages contain overall fewer bugs.

And if a bug does turn up, the identification and cor-rectioncanbemoreeffectiveandfaster.Thisisthetraitwhichisextremelyrelevantinthefieldofsecurity.

12

SHORTER ITERATIONFEWER BUGFIXES

Being the main technological partner of Netlock Ltd. the leading, qualified CertificateAuthority in Hungary,we are especially proud of our PKI-related develop-ment know-how.

Inourcustomdevelopmentprojectsweprovidediffer-ent PKI solutions (the use of certificates, timestamps,etc.), which can grant authenticity and undeniability in accordance with customer needs.

We have great expertise in building in such enhanced security controls into various functions.

13

AUTHENTICITY &UNDENIABILITY

The most typical point of failure is the human factor, so awareness, consciousness and preparedness of our colleagues is key.

To keep this factor always in focus, the guarantee is our ISO27001 information security management system (ISMS), whose practical procedures include recurring security trainings, professional studies, and continuous self-inspection proceedings.

14

AWARENESSVIGILANCE

We work in close cooperation with a software security facility accredited by the OCSI, under the Italian Com-mon Criteria (CC) Scheme.

The laboratory’s main profile is security support forsoftware development and software evaluations up to EAL4+ level.

During this partnership, we have managed to clarify a number of considerations and directives based on the CC.

We strive to start all of our projects to be fit for the EAL4+ definition, and bring “methodically designed, tested, and reviewed” softwares into existence.

15

CORRESPONDINGPARTNERSHIP

CONTACT US FOR A CONSULTATION:

WEB: dosell.ioEMAIL: tibor.zahorecz@dosell.ioMOBILE: +36 30 836 4099

LET US HELP YOU WITH SECURE SOFTWARE DEVELOPMENT!