Sunday, May 6, 2018

To solve the issue of error - Could not create the Java virtual machine in 11g Jdeveloper

To solve the issue of error - Could not create the Java virtual machine

open the project file of Jdeveloper 

For me i found it in below location 

file name

I have added the last two lines and it solves the issue 


Attaching the content of the  file, in last of this document.

after adding above two lines i can compile the SOA projects successfully, with additional message  Picked up _JAVA_OPTIONS

Total time: 10 seconds
Picked up _JAVA_OPTIONS: -Xmx512M

Content of File ->

#Tue Jan 02 12:04:10 IST 2018

Tuesday, January 30, 2018

Template of Impact Analysis Report

Impact Analysis Report
Version: draft
31st January,2018
Table of Contents
1. Introduction............................................................................................................................ 2
2. Glossary................................................................................................................................. 2
3. Determination of Assurance Continuity Application............................................................ 2
4. Impact Analysis Report Preparation..................................................................................... 3
(1) Introduction......................................................................................................................... 4
(2) Description of Changes....................................................................................................... 4
(3) Affected Developer Evidence.............................................................................................. 6
(4) Description of Developer Evidence Modifications................................................................ 7
(5) Conclusion.......................................................................................................................... 8
(6) Appendix........................................................................................................................... 10
5. Examination of the Impact Analysis Report....................................................................... 11

1. Introduction

This document should be used as a reference when considering application for assurance continuity. It contains viewpoints in determining whether changes to TOE are within the scope of assurance continuity, and cites examples of the contents of an “Impact Analysis Report” necessary for assurance continuity application.

2. Glossary

The meanings of terms used in this guidance document are equivalent to those used in “Assurance Continuity Guideline for Information Technology Security Certification.” The following are the meanings of main terms:
Certified TOE
The TOE version which has been evaluated and for which a “certificate” has already been issued.
Changed TOE
A version of TOE different from a certified TOE resulting from changes being applied to a certified TOE.
Developer Documentation
All necessary items describing the content of changes of a changed TOE with regard to a certified TOE. The items must be usable for verification.

3. Determination of Assurance Continuity Application

“Changes” made to a certified TOE subject to assurance continuity are not intended to apply to new products and functions derived from a certified TOE. Within the scope of security function specifications that had been evaluated for the certified TOE, only those “changes” for which, without requiring a third-party evaluation, developers (applicants) on their own responsibility can verify and claim that assurance will not be adversely affected will be applicable for assurance continuity. Such changes would include corrections to software and guidance defects or operational environment additions which do not incur changes to TOE functions.
There are no absolute indicators for judging whether “changes” to a certified TOE have a major effect or minor effect on security, including examples mentioned herein. Basically, the conditions for assurance continuity are that the developer him/herself analyses that the assurance of a certified TOE is not changed and can declare as such along with the results of the analysis, and that the contents of documentation that had been employed in the evaluation of a certified TOE have not been changed semantically.
It is surmised that major impacts will arise from changes to security functions provided by TOE, security problem definitions and requirements on ST, and evaluated security procedures. On the other hand, it is thought that corrections of typographical errors in the guidance and object changes due to comment line additions which are not executed will have a minor impact. In many cases, however, the question of whether changes to a certified TOE have a major impact on security or a minor impact on security will be determined by developer analysis.
The determination of the impact that changes will have on security will be based on an understanding of the assurance scope of the certified TOE and claims based on developer analysis. If changes clearly do not affect the assurance scope of the certified TOE, the changed TOE will be applicable for assurance continuity. If changes clearly affect the assurance scope of the certified TOE, re-evaluation will be necessary if impact is major. If impact is minor, it will be necessary to make such a claim and compile an Impact Analysis Report. In all other cases (if impact of changes is not clear), developers should conduct impact analysis and judge the extent of impacts.
As a reference to determine whether changes adversely affect the assurance scope of the certified TOE, a “Checklist for Assurance Continuity Application” is provided as an addendum to this document. The checklist provides a general summary of the kinds of items that are evaluated and assured at each assurance level. Confirming the degree of relevance that changes have to the assurance scope before implementing a detailed impact analysis for each change will enable one decide on a re-evaluation without compiling an Impact Analysis Report or to focus on specific areas for in-depth analysis. Of course, when a re-evaluation is decided, since an Impact Analysis Report compiled by developers will be useful for evaluators, one can choose to compile an Impact Analysis Report irrespective of the scope of impact on security or application for assurance continuity.

4. Impact Analysis Report Preparation

If the developer judges that the changes do not adversely affect the assurance scope of the certified TOE, the developer will conduct analysis of the content of changes, and will examine the impact on security. To apply for assurance continuity, the results of impact analysis must be compiled into a report. The minimum contents which must be included in the Impact Analysis Report are indicated in chapter 4 of “Assurance Continuity Guideline for Information Technology Security Certification.”
The Impact Analysis Report will not be published by the certification body. It is also possible to include non-public information. The “assurance continuity maintenance report” which is published information relating to assurance continuity will be prepared by the certification body based on this Impact Analysis Report.
Examples and points to keep in mind when preparing the Impact Analysis Report are shown below according to the composition of the Impact Analysis Report. Note that description formats other than the composition of the chapters can be arbitrary, and do not need to follow the examples.
Figure 1: Composition of Impact Analysis Report

(1) Introduction

The introduction shall describe identification information for requisite materials. It may also contain information for which developers have determined as particularly requiring caution, such as the handling of the report.
1.1 Impact Analysis Report Identification
Name of Document:         JISEC Ewallet Type C Impact Analysis Report
Version of Document:      1.0.1
Creation Date:                 2007-12-11
Author:                            JISEC Co., Ltd. Author Name 1, Author Name 2
1.2 TOE Identification
Name of Product:             JIEC Ewallet Type C
Name of TOE:                 JISEC Ewallet SecureTrade
Version of TOE:               Rev. 3
Developer:                       JISEC Co., Ltd.
1.3 Certified TOE Identification
Certification No.:             C00XX
Name of Product:             JISEC Ewallet Type C/D
Name of TOE:                  JISEC Ewallet SecureTrade
Version of TOE:               Rev. 2
Evaluation Assurance Level: EAL3
PP Conformance:             There is no PP to be conformed.

(2) Description of Changes

The description of changes shall describe all changes made to the certified TOE. Regarding changes to the assurance scope of the certified TOE, all changes including those judged not to affect security shall be described. It is not necessary to include those items (package design, etc.) which are clearly unrelated to the scope of the assurance level. However, this does not mean that impact analysis will be confined to the scope of the assurance level. If necessary, the impact on the assurance level of the certified TOE shall be examined through analysis which extends beyond the assurance level.
The reason for changes, changes to products including TOE, changes to the development environment, and changes to the IT environment shall be described in the description of changes.
a. Purpose of changes
The description of changes shall first explain the background for why changes to the TOE became necessary. This section shall describe an overview of the changes with regard to the certified TOE. The details of each change will be described in subsequent sections.
2.1 Purpose of Changes
Additions to the guidance documentation relating to new operating hardware, functional improvements, and flaw remediation have been performed. The following is an overview of these changes:
1)  Guidance modifications in response to new Type D additions to JISEC Ewallet on which TOE operates. There are no changes to the TOE program itself due to these additions.
2)  Program modifications to shorten boot time as automatic reboot was taking too long in the event of authentication failures.
3)  Program modifications in response to an implementation bug in which log information becomes empty when the audit log reaches the specified capacity during log information acquisition and file renaming is conducted.
In the event that there are numerous small bug fixes that do not involve specification changes, it is acceptable to describe the overall purpose in this section (boundary value issues in the implementation, performance improvement, etc.) and to describe the contents of each change in subsequent sections.
b. Changes to products
These descriptions relate to changes made to certified TOE. Regarding the level of detail of these descriptions, the information included shall have sufficient precision for a third party (certification body) to be able to understand the developer’s impact analysis claims, and in some situations, to call for the submission of additional documentation that shall be required for the judgement of applicability of assurance continuity.
Clearly describe in the descriptions of the assurance scope of the certified TOE, where the changes were made (whether to the source code or to the procedure manual, etc.), why these changes were made, and specifically how they were changed. If the assurance level of the certified TOE was EAL2, it is sufficient to describe changes at the level of functional specifications; descriptions at the module or source code level will not be called for.
Type of Change
Performance improvement
Improving auto reboot time in the event of authentication failures
The boot routine program was changed, and verification of TSF parameter values, network release and network restructuring conducted during booting are skipped if authentication failure flag is set and the system error flag is not set.
c. Changes to the development environment
These descriptions describe changes made to the development environment. All changes falling within the scope of assurance requirements for the certified TOE including those points judged to have a minor impact shall be listed. All changes, for example, such as changes to versions of TOE configuration items in configuration management, changes to the method of identifying configuration items, and changes to configuration management procedures, among others.
Development security
Changes to equipment for controlling entry to the development environment
Employee cards were updated, and the equipment for entry control to the development room was changed from authentication using old employee cards (magnetic) to authentication using new employee cards (contactless IC cards). There were no changes to entry procedures, etc.
d. Changes to the IT environment
Describe the changes to the IT environment for the certified TOE. This environment includes hardware, firmware, and software requiring security functions which are subject to evaluation such as external services that the TOE depends on, among others. It also includes all hardware, firmware, and software constituting the TOE operational environment.
Operating hardware
Additions to operating hardware
Additional operating assurances for “ISEC SS V.7”, OEM version of the operating hardware “JISEC SecureSwitch 07”.

(3) Affected Developer Evidence

Identify all developer evidence that were used in evaluating the certified TOE and which will require changes or additions. Developer evidence refers to all elements used as useful input in assisting the evaluator in evaluating the certified TOE. Specifically, it refers to documentation required to be submitted or necessary for the implementation of “developer action elements” which are identified in each assurance element of the security assurance components of CC Part 3.
Developers shall determine which developer evidence to update according to the changes made to the TOE and environment indicated in the previous description of changes. This determination shall employ a systematic method which considers the respective assurance components of certified TOE. This section shall list only the identification of developer evidences to be updated. The impact on each assurance component shall be determined with reference to chapter 3 “Performing Impact Analysis” in the “Assurance Continuity Guideline for Information Technology Security Certification.” For example, there are methods such as identifying the details of developer evidence associated with each developer action element as shown in the table below, and confirming their impact.
Action Elements
Developer Documentation
JISEC SmartModule Security Target Version3.1
ST introduction
JISEC SmartModule Security Target Version3.1
Conformance claims
JISEC SmartModule Functional testing

Of the developer evidences identified, this section calls for listing only those which need to be updated as affected developer evidence. How these changes are associated with the assurance scope of the certified TOE and what impacts they have are described in the next section.

(4) Description of Developer Evidence Modifications

Describe an overview of the changes to all developer evidence identified in “(3) Affected Developer Evidence”. While it is not necessary to provide a detailed description of changes to developer evidence, describe clearly and concisely what was changed, why, and how it was changed.
There are no common standards for judging how changes to certified TOE affect TOE assurance. A minor change could affect every aspect of assurance. Conversely, many modifications to a TOE may have minor impact on the assurance of TOE. In updating identified developer evidence, developers can judge what kinds of updates within the assurance scope of certified TOE are necessary by considering the “content and presentation elements” which correspond to these developer action elements. For example, AGD_PRE.1.2C states that “the preparative procedures shall describe all the steps necessary for secure installation of the TOE and for the secure preparation of the operational environment in accordance with the security objectives for the operational environment as described in the ST.” In other words, changes to the applicable descriptions in ST are required to be consistent with TOE acceptance and installation procedures. Regarding changes to certified TOE, developers can systematically determine the assurance scope and impact, by considering how to update developer evidence from the perspective of satisfying the corresponding “content and presentation elements,” and not by relying on experience or speculation.
In this section, describe the content of the changes in appropriate units such as for each assurance component, each change item, or each updated developer evidence, along with their references.
JISEC EasyLAN Functional Specifications
Section Number
Content of Changes
Location of Change
In response to not supporting FDDI:
removed FDDI from installation menu
removed FDDI message for error number [4]
Added verification logic for the code for IPA to the license key CD verification program.
In updating developer evidence, it is necessary to confirm that functions of the certified TOE other than those changed operate correctly (regression test). Similarly, if an assurance component from the AVA class is included in the assurance components, confirm that there were no impacts with regard to vulnerability. These will be confirmed by re-performing the tests, etc. that had been conducted when evaluating the certified TOE. Even if there are no major changes to security functions, there may be cases where new tests will be required. In such cases, it is necessary the developer include in the Impact Analysis Report what tests were additionally implemented and for what purpose. Also, countermeasures to new vulnerabilities after the evaluation of the certified TOE are not included in the assurance continuity scope. It is necessary they be “re-evaluated” to be included in the scope of assurance.

(5) Conclusion

Describe the judgements of whether the changes have a major impact or a minor impact on developer evidence together with the rationale for these judgements.
a. Impact of each change
Describe the impact of each change to developer evidence on the assurance of certified TOE. Also with regard to the rationales for these claims, outline the developer’s impact analysis results in relation to “(2) Description of Changes” and “(4) Description of Developer Evidence Modifications.”
Developers shall analyse the impacts of these changes across a broad range and at sufficient depth. To confirm that the certified assurance scope is not affected, analysis at a deeper level than the assurance level for the certified TOE will be necessary. In the event that changes to the source code of a given module does not involve direct changes to the external interface but may affect the error code of an indirectly called security function, a review of the source code is more efficient than confirming with a regression test using all error patterns as parameters. From this perspective, it is desirable that analysis of the specific impact of changes should be performed by a developer possessing technical knowledge of the changed TOE, and that analysis of how the results affect assurance be supported by a developer possessing knowledge of CC. TOE engineers understand the need to be aware that even small changes to the start-up script will affect the start-up timing and processing time assumed for other functions. CC engineers also understand the need to determine not only whether the message displayed by the script accurately reflects the functional specifications, but also that they are appropriate representations in the preparative procedures for conducting a secure installation.
Based on the results of the analysis of the impact of changes, developers shall determine whether these changes have a major impact or a minor impact, and shall report it along with their rationales. There is no general method for identifying whether impacts are major or minor. Refer to the addendum of the “Assurance Continuity Guideline for Information Technology Security Certification” for a general guideline.
[S3-3] Revision of the time-out period in the event of client communication disconnections
This is a program change relating to error processing of a post-processing process for service authentication of a security function which involves impacts to specifications and administrator guidance. However, it is judged as follows that there are no direct impacts to the interface relating to security function behaviour and secure management by the administrator, and that the impacts of these changes are minor.
In the specifications for “service authentication functions” in “Flow Manager Utility functions specifications,” the affects of post-processing are as follows:
1) There are no changes to the post-processing call method or to parameters.
2) During post-processing,
      There are no interactions with the users or other modules.
      There are no operations interrupted (including during the shortened 7 seconds)
3) At the completion of post-processing,
      There is no change to the error number returned. In other words, there is no change in the specification with regard to the error number [7] of error processing of the service authentication function.
      There are no other processes which are dependent on post-processing timing.
      Although message timing displayed on the administrator interface will be 7 seconds earlier, the impact is minor as described in S3-2(G).1.
The impact from changes to “Flow Manager Utility functions specifications” is judged to be minor.
Impacts of the change to the descriptions relating to time until error message display (“approx.10 seconds later” → “3 seconds later”) in “Service authentication” of “Flow Manager Utility Guidance” are as follows:
1) There are no security management items involved during the time from service authentication start-up until error message display.
2) There are no changes to the content of the displayed error message, nor any changes to the actions to be taken by the administrator after message confirmation.
Therefore, impacts from the change to “Flow Manager Utility Guidance” are judged to be minor.
Furthermore, describe the results of confirming (through regression tests) that security functions operate similarly for the changed TOE as they do for the certified TOE. It is not necessary to describe test procedures and detailed information in the Impact Analysis Report. The developer shall describe the perspective from which the test was implemented to confirm maintenance of assurance.
b. Overall impact
While changes may have little impact individually, they may have a major impact on a TOE through accumulation or interaction. Developers shall analyse each individual change as well as the overall impact on the TOE as a result of these changes. This section shall determine significance of the impact from the analysis results, and shall describe it along with its rationale.
S1-F and S2-F are changes to processing during installation and during operation respectively. As there is no interaction between them, TOE operation is not affected due to their combination. Furthermore, the guidance documents which reflect the respective changes consist of a procedure manual used at the preparation stage, and a guidance document used during operation. They are meant to be read by the administrator at different, independent phases and are contextually unrelated. Therefore, their combination will have no impact on TOE assurance.

(6) Appendix

Describe the identifications and list of items of the developer evidences updated by the changes.
a. List of updated developer evidences
Describe the information necessary to identify developer evidence for the changed TOE as a list including developer evidence name, issue date, and version, among others.
b. List of updated items of developer evidences
Describe the information necessary to identify changed items; that is, a list of the changed items and changed areas of each updated developer evidence. It is not necessary to include minor changes which are not related to the impact analysis (for example, the approval date for revisions).


5. Examination of the Impact Analysis Report

The certification body will determine the impact that each change has on assurance based on the submitted Impact Analysis Report. The Impact Analysis Report need not describe the detailed steps of impact analysis or test procedures. However, in the event the Impact Analysis Report contains non-technical analysis and enumeration of subjective claims such as “it is thought not to have an impact” or contains contradictory analysis results, and the certification body judges it necessary to confirm the content of changes and rationale of the analysis, the developer may be requested to provide development evidence or a detailed impact analysis evidence. Impact analysis evidence may be submitted in any format, provided the analysis process to derive the results of each impact analysis can be understood.