                       Intrusion and Surveillance Items
   1. Does the rule BIS is proposing control "intrusion software", malware, exploits, etc.?
      No, the proposed rule would not control any "intrusion software," which may also be referred to as malware or exploits. The Category 4 control entries would control the command and delivery platforms for generating, operating, delivering, and communicating with "intrusion software". It would also control the technology for developing "intrusion software," but it does not control the "intrusion software" itself.
      Thus, transferring or exporting exploit samples, exploit proof of concepts, or other forms of malware would not be included in the new control list entries and would not require a license under the proposed rule.
   2. Doesn't the rule potentially criminalize hacking?
      No. The rule would control the export of hardware and software delivery tools, as well as the export of technical data for developing exploits ("intrusion software"). The rule as proposed would not control the export of exploits to a target system since "intrusion software" would not be controlled. Also, the Export Administration Regulations (EAR) do not control services, only the export of commodities, software and technology. Thus, "hacking", as that term is generally understood, does not fall under the jurisdiction of the EAR, except to the extent there is an associated export of hardware, software, or technical data.
   3. Does the rule inadvertently capture defensive products as well as offensive products?
      The proposed rule would control the command and delivery platforms "specially designed" or modified for generating, operating, delivering, or communicating with "intrusion software" as defined in the EAR. As noted in the preamble to the proposed rule, some penetration testing products marketed as defensive products meet the technical description of such command and delivery platforms in the new control list entries. BIS is not aware of other defensive products that would be caught by the proposed rule, but would welcome comments on this. If penetration testing products are determined to be described in the Category 4 control list entries, they will be deleted from the list of products eligible for export under License Exception ENC (section 740.17(b)(2)(i)(F)).
   4. Will the rule control vulnerability research as well as research on exploits?
      The rule would control the export of technology for the "development" of "intrusion software", as well as the technology for the "development" or "production" of the command and delivery platforms themselves. A license would not be required simply to conduct research or analyze code, unless there was an associated transfer or deemed export of controlled technology, executable software, or source code.
      As a clarification, the proposed rule would control the following, among other things:
         1.                   Information "required for" developing, testing, refining, and evaluating "intrusion software", in order, for example, technical data to create a controllable exploit that can reliably and predictably defeat protective countermeasures and extract information.
         2.                   Information on how to prepare the exploit for delivery or integrate it into a command and delivery platform.
         3.                   The development or production of the command and delivery platform itself.
      The proposed rule would not control the following:
         1.                   Information on how to search for, discover or identify a vulnerability in a system, including vulnerability scanning;
         2.                   Information about the vulnerability, including causes of the vulnerability; and
         3.                   Information on testing the vulnerability, including `fuzzing' or otherwise trying different inputs to determine what happens; and
         4.                   Information on analyzing the execution or functionality of programs and processes running on a computer, including decompiling or disassembling code and dumping memory.
      In addition, there are two further limitations to controls on technology:
      First, not all malware and exploits meet the definition of "intrusion software". The definition specifies only intrusion software that is capable of extracting or modifying data or modifying the standard execution path of software in order to allow the execution of externally provided instructions. Thus, technology for the development of malware that is designed to do other things, such as damage or destroy systems or infrastructure, would not be controlled under the proposed rule.
      Second, the only technology controlled is the technology that is "required for" and peculiarly responsible for achieving or exceeding the control level. See BIS's 3/25/14 advisory opinion at http://www.bis.doc.gov/index.php/policy-guidance/advisory-opinions.
      Third, export controls do not apply to any technology or software that is "published" or otherwise made publicly available.
      Thus, only that part of the technology that is peculiarly responsible for meeting the definition of "intrusion software" , and is not publicly available, would be controlled.
      As part of the request for comments, BIS is seeking comments from the public on further clarifications that may be needed on this subject.
   5. Doesn't the rule expose researchers to criminal prosecution if they carry information on exploits to a public conference, unless they publish it before the conference?
      Under Section 734.7 of the EAR, information that is published, or released at an open conference, is not subject to the EAR. That section also specifies that it would not be an export to transfer the technical data to conference organizers with the intent that it will be published at the conference.
      BIS welcomes comments on whether further clarification is needed on when information potentially subject to these rules would be considered "publicly available" and not subject to the EAR.
   6. Doesn't the rule make it easier for researchers to provide exploitable bugs to their government then to publish an exploit in order to fix and alert the world of the problem?
      Under Section 734.7, there are no restraints on publishing information otherwise subject to control, and no prior authorization from BIS is required. Once the information is published it is not subject to the EAR. Thus any information that is published is completely outside the scope of the EAR and the provisions of the proposed rule.
   7. Will companies be required to share their zero-day exploits with the government in order to get a license?
      The rule states that when an export license application is filed, BIS can request a copy of the part of the software or source code that implements the controlled cybersecurity functionality. Exploits that meet the definition of "intrusion software" are not controlled. Therefore, BIS would not request a company to share a zero-day exploit. Please see FAQ #15.
   8. Does the rule capture auto-updaters and anti-virus software?
      No. Software that permits automatic updates and anti-virus tools are not described in proposed ECCN 4D004. ECCN 4D004 software must be specially designed or modified for the generation, operation or delivery of, of communication with, "intrusion software," which is separately defined. Anti-virus software is a `monitoring tool' that is explicitly excluded from the definition of "intrusion software. Further, software that automatically updates itself may need to interact with installed `monitoring tools" and protective countermeasures in order to properly execute, but they are not defeating (or otherwise subverting) the system or generating, operating, delivering, or communicating with "intrusion software".
   9. Would ECCN 4E001.c be covered by the General Technology Note?
      Yes. Per the advisory opinion issued by BIS on 3/25/14, the GTN applies to all ECCNs controlling ''technology," regardless of whether the ECCN specifically refers to the GTN or uses the term "required."
   10. If an IT security researcher had done an analysis on a software application to find a vulnerability in the code, had written up code to then take advantage of the vulnerability and then sent that code to an anti-virus company or the software manufacturer, would that code require an export license?
      No, what is described is the creation of an "exploit." Exploits are not described in the text of the proposed control list entries. The code that takes advantage of the vulnerability would not require a license. As stated above, "intrusion software" itself would not be controlled by the proposed rule.
      For any associated technology for the "development" of "intrusion software", under section 734.7 of the EAR, any technical data sent to an anti-virus company or software manufacturer with the understanding that the information will be made publicly available, would not be subject to the EAR. However, "technology" that is not intended to be published would be subject to the control  -  see question #4.
   11. The first FAQ basically equates "intrusion software" with malware and exploits. Is this the intent?
      The definition of "intrusion software" is meant to include a subset of all the malware (exploits, viruses, etc.) that are out there. The definition describes only "intrusion software" that is specially designed to extract or modify data or modify the standard execution path of software in order to allow the execution of externally provided instructions. Other types of malware, including software that only leaves evidence of a successful security breach without further compromising or controlled the system, or is designed to destroy data or systems would not be included in the definition of "intrusion software."
   12. There is a reference to penetration testing products in another FAQ. Is that to say that all penetration testing products would fit the definition of "intrusion software"?
      Some penetration testing products meet the description of systems, equipment or software "specially designed" or modified for the generation, operation or delivery of, or communication with, "intrusion software" set forth in proposed ECCNs 4A005 and 4D004. The tools that meet the entry are ones that are "specially designed" or modified to launch exploits or other malware that meet the definition of "intrusion software"  -  including extracting or modifying data on the system.
      However, there are some tools that are used in penetration testing that are not caught by the entries because they do not do the things described in the definition. For example, tools such as port scanners, packet sniffers and protocol analyzers would not be controlled. A penetration testing tool not designed to avoid detection by `monitoring tools' would not be controlled. Also, a vulnerability scanner, which just finds vulnerabilities in a system without actually exploiting them and extracting data, would not be captured by the proposed rule.
   13. There are defensive products on the market that would probe a network for vulnerabilities (while avoiding the monitoring tools) and would then extract some sample data from the target system to prove that the vulnerability is real. However, that data extraction is benign and merely done as a proof of the vulnerability. The entire process - from the product's capabilities on what it extracts to the act of using it - is done as a defensive act. Would this be considered meet the definition of "intrusion software?"
      Such products would meet the technical description of systems, equipment or software "specially designed" or modified for the generation, operation or delivery of, or communication with, "intrusion software" set forth in proposed ECCNs 4A005 and 4D004. It is BIS's understanding that there is no technical basis to distinguish defensive products from offensive products (i.e., a defensive product may be used offensively).
   14. Is there a definition of "carrier class IP network" (for ECCN 5A001.j)?
      The term "carrier class IP network" is meant to specify systems that sit at a national level (or large regional) IP backbone and handle data from an entire city or country. In terms of IP network surveillance systems, this is meant to exclude systems that can only handle smaller data streams or networks, such as those for a campus or a neighborhood. This control does not capture systems that can only analyze data from one person or a small group of people at a time. The term "carrier class IP network" was not defined because it was difficult to put precise technical parameters around this concept.
   15. The answer to FAQ #1 says "exploit samples, exploit proof of concepts, or other forms of malware would not be included" yet the answer to FAQ #7 appears to keep the door open for "zero-day exploits". Can you please clarify your definition of "zero-day exploit" and provide discriminating characteristics to differentiate it from the "exploit samples, exploit proof of concepts" that are explicitly excluded by question 1?
      This is a two-part answer. First, the answer to FAQ #1 states that the proposed rule does not control the export of exploits and other forms of malware. Zero-day exploits are included in this answer. The export of zero-day exploits, however the term "zero-day" is defined, is not subject to any requirements under the proposed rule.
      Second, FAQ #7 asks whether companies will be required to share their zero-day exploits with the government in order to get a license. The answer to FAQ #7 states that when an export license application is filed, BIS can request a copy of the part of the software or source code that implements the controlled functionality. To expand this answer, the export license requirement applies to the system, equipment, component or software that would generate, operate, deliver or communicate with an exploit. The only regulatory distinction involving zero- day exploits in the proposed rule regards the possibility that a delivery tool could either have (e.g., incorporate) or support (e.g., be `specially designed" or modified to operate, deliver or communicate with) zero-day exploits. If the system, equipment component or software at issue has or supports zero-day or rootkit capabilities, then BIS could request the part of the software or source code that implements that capability. BIS does not anticipate receiving many, or any, export license applications for products having or supporting zero-day capabilities.
   16. Is the United States legally bound to implement the December 2013 Wassenaar Arrangement changes to its control list, or does BIS have discretion?
      The United States, as a Participating State in the Wassenaar Arrangement, has agreed to maintain national export controls on items included in the Wassenaar Arrangement's control lists, implemented via national legislation and/or regulation. The U.S. implementation process includes determining reason(s) for control, which carry with them license requirements by destination, licensing policy, and license exceptions.
   17. How would the proposed rule affect software used by multinational companies that monitor their overseas networks?
      Under the proposed rule, all exports of specified systems, equipment, components or software that would generate, operate, deliver or communicate with "intrusion software" would require an export license. There is no license exception for intra-company transfers or internal use by a company headquartered in the United States under the proposed rule.
   18. Security professionals use exploit toolkits (e.g. Neosploit, Blackhole, Phoenix, Crimepack &c.) to test patches and harden systems employing the same tools as a potential criminal adversary. Distribution and licensing of such toolkits is tightly controlled in order to preserve their offensive edge. When security professionals succeed in accessing or acquiring these toolkits, they often share with one another across corporate and international boundaries; would such sharing of exploit toolkits be subject to control?
      Exploit toolkits would be described in proposed ECCN 4D004 if they are "specially designed" or modified for the generation of "intrusion software." There are no end user or end use license exceptions in the proposed rule.
   19. Security research is intellectually demanding, skilled work. Corporate entities recognize this both by compensating their contracted security professionals accordingly, and by compensating independent researchers who find and report vulnerabilities in their digital infrastructure. These 'bug bounties' are not generally awarded in the absence of a fully-elaborated proof of concept, which is functionally identical to an `exploit'; the vulnerability must be shown to be exploitable and its severity level should be made known to the vendor. What, if any, implications does the proposed rule hold for: i. `Silent' disclosures, in which the researcher may be compensated, but neither the vendor nor the researcher publicly disclose (`publish') the vulnerability? (Most often a vendor choice.); ii. Disclosures in which a vulnerability is made public, but its proof of concept is not; iii. Disclosure of any stripe made through an intermediary (i.e. to HackerOne or via a legal representative)?
      First, the proposed rule would only apply to exports and reexports of software described in the new control list entries. Domestic commerce in exploits is not subject to the requirements of the Export Administration Regulations.
      Second, in none of the scenarios above would the exploit or proof of concept be considered to be software described in the new control list entries. See questions 4 and 10.
      Finally, if an export is at issue, it is possible that certain technology associated with the exploit would be "technology required for the development or production of intrusion software" under proposed ECCN 4E001.c. As stated in the answer to FAQ #10, any technical data that is transferred with the intent that it be published would not be controlled. However, as the
      question recognizes, not all technical data is intended to be made public, and some of it may be controlled.
   20. When vulnerabilities are found and proofs of concept developed from flaws in proprietary systems, does this have bearing on the classification of security research as `fundamental'? What about when access to that proprietary system is neither specifically authorized, nor unauthorized by the vendor?
      No, whether the system is proprietary or open source, and whether the access to the system is authorized by the vendor, does not affect whether the security research is "fundamental research." If the research is ordinarily published and shared broadly within the scientific community, it is "fundamental research." If the results of the research ordinarily are restricted for proprietary reasons, it is not. The answer to question 19 above describes a situation when such research would not be "fundamental research."
   21. Could BIS explain the regulatory difference between an open-source security tools (e.g. Metasploit, Kali Linux), and a proprietary surveillance platform (e.g. FinFisher) which may come packaged with open-source tools?
      Open source security tools such as those referenced that can be downloaded by anyone are not subject to the Export Administration Regulations . Proprietary tools that package and control such open source tools are subject to the regulations and may be described in the new control list entries.
   22. BIS has adopted the definition of `intrusion software' from the Wassenaar Arrangement language, but has elsewhere indicated a policy of `presumptive denial' for cybersecurity items `that incorporate or otherwise support rootkit or zero-day exploit functionality'. Could BIS explain what threshold of severity is meant to be indicated by `rootkit or zero-day exploit functionality', and could BIS make clear their understanding of those terms?
      Rootkit and zero-day exploit functionality are features more likely to be found in offensive systems or products. A zero-day exploit is not itself controlled. However, when a rootkit or a zero-day exploit is incorporated into a product or system that is described in the new Category 4 control list entries, or if an exploit delivery tool is specially programmed to deliver or command this specialized malware, that product or system is presumed to be offensive by design.
   23. In FAQ #9, BIS stated that the Wassenaar General Technology Note was incorporated into the BIS proposal. Does the Wassenaar General Software Note also apply?
      The "public domain" provisions (paragraph 2) of the Wassenaar General Software Note (GSN) apply, but the "mass market' provisions (paragraph 1), do not.
      Paragraph 1 of the General Software Note is implemented in the Export Administration Regulations in License Exception TSU (section 740.13(d)). The proposed rule excludes software described in the new control list entries from eligibility under this provision. This exclusion was added to the proposed rule because a similar exclusion applies to encryption software classified under ECCN 5D002, and software described in the new control list entries may incorporate encryption functionality. Software classified under ECCN 5D002 is separately eligible for decontrol to ECCN 5D992 pursuant to the provisions of section 742.15(b) for mass market encryption items. The proposed rule does not provide for any license exception eligibility for products under the new control list entries, except under License Exception GOV.
   24. Would prior BIS authorization be required for a researcher to privately disclose an exploit to a vendor outside the US with the understanding that the information would NOT be published?
      No. The exploit itself is not described in the new control list entries. Please see the answer to question #1. For this question, a vulnerability is a weakness in a vendor's software or hardware. Exploit code could be written to take advantage of the vulnerability or to prove that the vulnerability can be exploited. The exploit code itself may be considered "intrusion software." Neither the disclosure of the vulnerability nor the disclosure of the exploit code would be controlled under the proposed rule. However, information for the development of "intrusion software" that may accompany the disclosure of the exploit may be described in proposed new ECCN 4E001.c.
   25. In FAQ #10, BIS states that the new implementation would not control "code that takes advantage of [a] vulnerability." However, FAQ 4 states that "information on how to prepare the exploit for delivery" is controlled. We're confused as to how a researcher could submit to a vendor a functional proof of concept and accompanying explanatory material that according to FAQ 10 would not be controlled without violating the restriction from FAQ 4. This assumes that the disclosure to the vendor is not intended for publication.
      The functional proof of concept may be "intrusion software." The intrusion software itself is not described in the new control list entries (per FAQ #10). However, if technology "required for the development of intrusion software" (as described in the proposed control list entry ECCN 4E001.c.) exported with the functional proof of concept/"intrusion software" would be described in new control list entry ECCN 4E001.c and would, under the proposed rule, require a license to all destinations except Canada. This is what is addressed in the answer to Question #4.
   26. Mobile phone jailbreaking tools include platforms for delivering intrusion software to the phone. These generally include fully operational exploits including the delivery code. Are such tools subject to control?
      This response divides the question into two parts:
      i) Does this regulation make it illegal to jailbreak a phone?
      No. The Commerce regulation controls exports of certain software, and downloading jailbreaking software to a computer within the United States and using it to jailbreak a phone does not involve an export of software. The proposed rule does not limit the ability of owners to modify their devices.
      ii) What if the jailbreak software includes a platform for delivering intrusion software to the phone--is the jailbreak software subject to control?
      If particular jailbreak software did meet all the requirements for classification under ECCN 4D004 (such as a commercially sold delivery tool "specially designed" to deliver jailbreaking exploits) then it would be subject to control and a license would be required to export it from the United States. Note that if such software were "publicly available," it would not be subject to the Export Administration Regulations.
   27. In FAQ 7, BIS states companies are already required to share source code for exploits that include encryption or cryptanalysis. What about software tools that implement exploits that aren't already subject to encryption controls?
      The provision referred to is specific to requests to make encryption source code eligible for export under License Exception ENC. Supplement No. 6 to part 742, a questionnaire required to be submitted with requests for License Exception ENC authorization, provides that a copy of the sections of the source code that contain the encryption algorithm, key management routines and their related calls is to be included upon request. (Supp. No 6, paragraph (d)(3)). The proposed rule includes a similar provision for license applications for products that are described in the new control list entries in Supplement No. 2 to part 748, paragraph (z)(2): "Upon request, include a copy of the sections of source code and other software (e.g., libraries and header files) that implement or invoke the controlled cybersecurity functionality."
   28. Does "publicly available" as understood by BIS include a posting on the Internet?
      Yes, technology or software that is generally accessible to the interested public in any form, including by Internet post, is "publicly available."
   29. Most intrusion software is designed, written, and generated in general purpose programming environments (such as IDEs [integrated design environments]). We presume that BIS has no desire to control those types of tools. However, under the proposed rules, such environments are at least potentially within the controls. What does BIS mean when it says that "the development or production of the command and delivery platform itself" (FAQ 1) is controlled?
      General purpose tools, such as IDEs, are not described under proposed ECCN 4D004 because they are not "specially designed" for the generation of "intrusion software." Some penetration testing tools (FAQ #12) and exploit toolkits (FAQ #18) are described in proposed ECCN 4D004, as they are command and delivery platforms for "intrusion software."
   30. What does BIS mean by "modification of the standard execution path of a program or process in order to allow the execution of externally provided instructions"?
      This language is part of the definition of "intrusion software" and refers to a variety of techniques to hijack, or otherwise corrupt, a legitimate (or otherwise trusted) application or process running on the computer, mobile phone or other device. This can be done to create persistence or for other purposes. Through these modifications, a remote operator (or remote command and control software) can execute commands or perform other tasks that further compromise or exploit the hacked (penetrated) device.
   31. When the 2013 Wassenaar update added controls 4.A.5, 4.D.4, 4.E.1.c, and 5.A.1.j, it subjected all these categories to the exemptions available under the "General Software Note", ensuring that software and systems "generally available to the public" were not included in the new controlled classes. Yet the proposed BIS implementation of these controls excludes "cybersecurity software" from the BIS "General Software Note" (740.13.d) by adding paragraph 740.13.d.2.ii. Why has BIS chosen to depart from the 2013 Wassenaar language and exclude software covered by the new controls from the "General Software Note"?
      Please refer to the answer to FAQ #23. The exclusion of software described in the new control list entries from License Exception TSU (the implementation of paragraph 1 of the General Software Note in the Export Administration Regulations) was added for consistency with the treatment of encryption software classified under ECCN 5D002, as it is anticipated that many items that will be classified under the new control list entries have encryption functionality and are currently classified under ECCN 5D002. However, under the proposed rule, items classified under the new control list entries will not be eligible for decontrol in the same way that ECCN 5D002 products are if they are mass marketed (pursuant to Note 3 to Category 5 part 2 of the Commerce Control List and section 742.15(b) of the Export Administration Regulations).
   32. Will technology and source code classified under the new control list entries be subject to deemed export requirements?
      Yes, the proposed rule does not provide for any exceptions to deemed export license requirements for release of technology and source code that will be classified under ECCNs 4D004, 4E001.a or .c, 5D001 or 5E001.


[Federal Register Volume 79, Number 166 (Wednesday, August 27, 2014)]
[Rules and Regulations]
[Pages 51074-51077]
[FR Doc No: 2014-19683]

-----------------------------------------------------------------------

DEPARTMENT OF TRANSPORTATION

Federal Aviation Administration

14 CFR Part 39

[Docket No. FAA-2014-0234; Directorate Identifier 2013-NM-220-AD;
Amendment 39-17952; AD 2014-16-28 ]
RIN 2120-AA64

Airworthiness Directives; Empresa Brasileira de Aeronautica S.A.
(Embraer)

AGENCY: Federal Aviation Administration (FAA), Department of
Transportation (DOT).

ACTION: Final rule.

-----------------------------------------------------------------------

SUMMARY: We are adopting a new airworthiness directive (AD) for certain
Empresa Brasileira de Aeronautica S.A. (Embraer) Model EMB-135BJ
airplanes. This AD was prompted by reports of failure of the bolts that
connect the cockpit windshield center-post to the forward fuselage.
This AD requires repetitive detailed inspections to detect
discrepancies on the attaching parts of the cockpit windshield center-
post; checking whether the bolts are tightened, if applicable; and
modifying parts, including inspecting for and repairing damage. We are
issuing this AD to prevent failed bolts and failed attaching parts of
the cockpit windshield center-post, which could lead to loss of
structural integrity of the airplane.

DATES: This AD becomes effective October 1, 2014.
    The Director of the Federal Register approved the incorporation by
reference of a certain publication listed in this AD as of October 1,
2014.

ADDRESSES: You may examine the AD docket on the Internet at http://
www.regulations.gov#!docketDetail;D=FAA-2014-0234 or in person at the
Docket Management Facility, U.S. Department of Transportation, Docket
Operations, M-30, West Building Ground Floor, Room W12-140, 1200 New
Jersey Avenue SE., Washington, DC.
    For service information identified in this AD, contact Empresa
Brasileira de Aeronautica S.A. (Embraer), Technical Publications
Section (PC 060), Av. Brigadeiro Faria Lima, 2170--Putim--12227-901
S[atilde]o Jose dos Campos--SP--BRASIL; telephone +55 12 3927-5852 or
+55 12 3309-0732; fax +55 12 3927-7546; email<EMAIL_ADDRESS>
Internet http://www.flyembraer.com. You may view this referenced
service information at the FAA, Transport Airplane Directorate, 1601
Lind Avenue SW., Renton, WA. For information on the availability of
this material at the FAA, call<PHONE_NUMBER>.

FOR FURTHER INFORMATION CONTACT: Todd Thompson, Aerospace Engineer,
International Branch, ANM-116, Transport Airplane Directorate, FAA,
1601 Lind Avenue SW., Renton, WA 98057-3356; telephone<PHONE_NUMBER>;
fax<PHONE_NUMBER>.

SUPPLEMENTARY INFORMATION:

Discussion

    We issued a notice of proposed rulemaking (NPRM) to amend 14 CFR
part 39 by adding an AD that would apply to certain Empresa Brasileira
de Aeronautica S.A. (Embraer) Model EMB-135BJ airplanes. The NPRM
published in the Federal Register on April 15, 2014 (79 FR 21160).
    The Ag[ecirc]ncia Nacional de Avia[ccedil][atilde]o Civil (ANAC),
which is the aviation authority for Brazil, has issued Brazilian
Airworthiness Directive 2013-10-02, dated October 23, 2013 (referred to
after this as the Mandatory Continuing Airworthiness Information, or
``the MCAI''), to correct an unsafe condition certain Empresa
Brasileira de Aeronautica S.A. (Embraer) Model EMB-135BJ airplanes. The
MCAI states:

    This [Brazilian] AD was prompted by reports of failure of the
bolts that connect the lower eyelet fitting of the cockpit
windshield center-post to the forward fuselage. We are issuing this
[Brazilian] AD to detect failed bolts and correct the attaching
parts of the lower eyelet fitting of the cockpit windshield center-
post, which could lead to loss of structural integrity of the
airplane.

    Required actions include repetitive detailed inspections for
discrepancies on the attaching parts of the lower eyelet fitting of the
cockpit windshield center-post; a bolt check, if applicable; and
modification of the attaching parts of the lower eyelet fitting of the
cockpit windshield center-post, including a general visual inspection
for damage of the specified lower eyelet fitting and repair of the
damage. The modification would terminate the repetitive detailed
inspections. You may examine the MCAI in the AD docket on the Internet
at http://www.regulations.gov/#!documentDetail;D=FAA-2014-0234-0002.

Comments

    We gave the public the opportunity to participate in developing
this AD. We received no comments on the NPRM (79 FR 21160, April 15,
2014) or on the determination of the cost to the public.

``Contacting the Manufacturer'' Paragraph in This AD

    Since late 2006, we have included a standard paragraph titled
``Airworthy Product'' in all MCAI ADs in which the FAA develops an AD
based on a foreign authority's AD.
    The MCAI or referenced service information in an FAA AD often
directs the owner/operator to contact the manufacturer for corrective
actions, such as a repair. Briefly, the Airworthy Product paragraph
allowed owners/operators to use corrective actions provided by the
manufacturer if those actions were FAA-approved. In addition, the
paragraph stated that any actions approved by the State of Design
Authority (or its delegated agent) are considered to be FAA-approved.
    In the NPRM (79 FR 21160, April 15, 2014), we proposed to prevent
the use of repairs that were not specifically developed to correct the
unsafe condition, by requiring that the repair approval provided by the
State of Design Authority or its delegated agent specifically refer to
this FAA AD. This change was intended to clarify the method of
compliance and to provide operators with better visibility of repairs
that are specifically developed and approved to correct the unsafe
condition. In addition, we proposed to change the phrase ``its
delegated agent'' to include a design approval holder (DAH) with State
of Design Authority design organization approval (DOA), as applicable,
to refer to a DAH authorized to approve required repairs for the
proposed AD.
    No comments were provided to the NPRM (79 FR 21160, April 15, 2014)
about these proposed changes. However, a comment was provided for an
NPRM having Directorate Identifier 2012-NM-101-AD (78 FR 78285,
December 26, 2013). The commenter stated the following: ``The proposed
wording, being specific to repairs, eliminates the interpretation that
Airbus messages are acceptable for approving minor deviations
(corrective actions) needed during accomplishment of an AD mandated
Airbus service bulletin.''
    This comment has made the FAA aware that some operators have
misunderstood or misinterpreted the Airworthy Product paragraph to
allow the owner/operator to use messages provided by the manufacturer
as approval of deviations during the accomplishment of an AD-mandated
action. The Airworthy Product paragraph does not approve messages or
other information provided by the manufacturer for deviations to the
requirements of the AD-mandated actions. The Airworthy Product
paragraph only addresses the requirement to contact the manufacturer
for corrective actions for the identified unsafe condition and does not
cover deviations from other AD requirements. However, deviations to AD-
required actions are addressed in 14 CFR 39.17, and anyone may request
the approval for an alternative method of compliance to the AD-required
actions using the procedures found in 14 CFR 39.19.
    To address this misunderstanding and misinterpretation of the
Airworthy Product paragraph, we have changed that paragraph and
retitled it ``Contacting the Manufacturer.'' This paragraph now
clarifies that for any requirement in this AD to obtain corrective
actions from a manufacturer, the action must be accomplished using a
method approved by the FAA, ANAC, or ANAC's authorized Designee.
    The Contacting the Manufacturer paragraph also clarifies that, if
approved by the ANAC Designee, the approval must include the Designee's
authorized signature. The Designee signature indicates that the data
and information contained in the document are ANAC-approved, which is
also FAA-approved. Messages and other information provided by the
manufacturer that do not contain the ANAC Designee's authorized
signature approval are not ANAC-approved, unless ANAC directly approves
the manufacturer's message or other information.
    This clarification does not remove flexibility previously afforded
by the Airworthy Product paragraph. Consistent with long-standing FAA
policy, such flexibility was never intended for required actions. This
is also consistent with the recommendation of the Airworthiness
Directive Implementation Aviation Rulemaking Committee to increase
flexibility in complying with ADs by identifying those actions in
manufacturers' service instructions that are ``Required for
Compliance'' with ADs. We continue to work with manufacturers to
implement this recommendation. But once we determine that an action is
required, any deviation from the requirement must be approved as an
alternative method of compliance.
    Other commenters to the NPRM having Directorate Identifier 2012-NM-
101-AD (78 FR 78285, December 26, 2013) pointed out that in many cases
the foreign manufacturer's service bulletin and the foreign authority's
MCAI might have been issued some time before the FAA AD. Therefore, the
DOA might have provided U.S. operators with an approved repair,
developed with full awareness of the unsafe condition, before the FAA
AD is issued. Under these circumstances, to comply with the FAA AD, the
operator would be required to go back to the manufacturer's DOA and
obtain a new approval document, adding time and expense to the
compliance process with no safety benefit.
    Based on these comments, we removed the requirement that the DAH-
provided repair specifically refer to this AD. Before adopting such a
requirement, the FAA will coordinate with affected DAHs and verify they
are prepared to implement means to ensure that their repair approvals
consider the unsafe condition addressed in this AD. Any such
requirements will be adopted through the normal AD rulemaking process,
including notice-and-comment procedures, when appropriate.
    We also have decided not to include a generic reference to either
the ``delegated agent'' or ``DAH with State of Design Authority design
organization approval,'' but instead we have provided the specific
delegation approval granted by the State of Design Authority for the
DAH throughout this AD.

Conclusion

    We reviewed the relevant data and determined that air safety and
the public interest require adopting this AD with the changes described
previously and minor editorial changes. We have determined that these
minor changes:
     Are consistent with the intent that was proposed in the
NPRM (79 FR 21160, April 15, 2014) for correcting the unsafe condition;
and
     Do not add any additional burden upon the public than was
already proposed in the NPRM (79 FR 21160, April 15, 2014).
    We also determined that these changes will not increase the
economic burden on any operator or increase the scope of this AD.

Costs of Compliance

    We estimate that this AD affects 56 airplanes of U.S. registry.
    We also estimate that it would take about 35 work-hours per product
to comply with the basic requirements of this AD. The average labor
rate is $85 per work hour. Required parts would cost about $386 per
product. Based on these figures, we estimate the cost of

this AD on U.S. operators to be $188,216, or $3,361 per product.
    We have received no definitive data that would enable us to provide
cost estimates for the on-condition actions specified in this AD.

Authority for This Rulemaking

    Title 49 of the United States Code specifies the FAA's authority to
issue rules on aviation safety. Subtitle I, section 106, describes the
authority of the FAA Administrator. ``Subtitle VII: Aviation
Programs,'' describes in more detail the scope of the Agency's
authority.
    We are issuing this rulemaking under the authority described in
``Subtitle VII, Part A, Subpart III, Section 44701: General
requirements.'' Under that section, Congress charges the FAA with
promoting safe flight of civil aircraft in air commerce by prescribing
regulations for practices, methods, and procedures the Administrator
finds necessary for safety in air commerce. This regulation is within
the scope of that authority because it addresses an unsafe condition
that is likely to exist or develop on products identified in this
rulemaking action.

Regulatory Findings

    We determined that this AD will not have federalism implications
under Executive Order 13132. This AD will not have a substantial direct
effect on the States, on the relationship between the national
government and the States, or on the distribution of power and
responsibilities among the various levels of government.
    For the reasons discussed above, I certify that this AD:
    1. Is not a ``significant regulatory action'' under Executive Order
12866;
    2. Is not a ``significant rule'' under the DOT Regulatory Policies
and Procedures (44 FR 11034, February 26, 1979);
    3. Will not affect intrastate aviation in Alaska; and
    4. Will not have a significant economic impact, positive or
negative, on a substantial number of small entities under the criteria
of the Regulatory Flexibility Act.

Examining the AD Docket

    You may examine the AD docket on the Internet at http://
www.regulations.gov#!docketDetail;D=FAA-2014-0234; or in person at the
Docket Management Facility between 9 a.m. and 5 p.m., Monday through
Friday, except Federal holidays. The AD docket contains this AD, the
regulatory evaluation, any comments received, and other information.
The street address for the Docket Operations office (telephone 800-647-
5527) is in the ADDRESSES section.

List of Subjects in 14 CFR Part 39

    Air transportation, Aircraft, Aviation safety, Incorporation by
reference, Safety.

Adoption of the Amendment

    Accordingly, under the authority delegated to me by the
Administrator, the FAA amends 14 CFR part 39 as follows:

PART 39--AIRWORTHINESS DIRECTIVES

0
1. The authority citation for part 39 continues to read as follows:

    Authority:  49 U.S.C. 106(g), 40113, 44701.

Sec.  39.13  [Amended]

0
2. The FAA amends Sec.  39.13 by adding the following new airworthiness
directive (AD):

2014-16-28 Empresa Brasileira de Aeronautica S.A. (Embraer):
Amendment 39-17952. Docket No. FAA-2014-0234; Directorate Identifier
2013-NM-220-AD.

(a) Effective Date

    This AD becomes effective October 1, 2014.

(b) Affected ADs

    None.

(c) Applicability

    This AD applies to Empresa Brasileira de Aeronautica S.A.
(Embraer) Model EMB-135BJ airplanes, certificated in any category,
as identified in Embraer Alert Service Bulletin 145LEG-53-A032,
Revision 01, dated September 24, 2013.

(d) Subject

    Air Transport Association (ATA) of America Code 53, Fuselage.

(e) Reason

    This AD was prompted by reports of failure of the bolts that
connect the cockpit windshield center-post to the forward fuselage.
We are issuing this AD to prevent failed bolts and failed attaching
parts of the cockpit windshield center-post, which could lead to
loss of structural integrity of the airplane.

(f) Compliance

    Comply with this AD within the compliance times specified,
unless already done.

(g) Detailed Inspection

    At the applicable time specified in paragraph (g)(1) or (g)(2)
of this AD, do a detailed inspection to detect discrepancies on the
attaching parts of the lower eyelet fitting of the cockpit
windshield center-post and, if applicable, check whether the bolts
are tightened, in accordance with Part I of the Accomplishment
Instructions of Embraer Alert Service Bulletin 145LEG-53-A032,
Revision 01, dated September 24, 2013. If any discrepancy is found
or if any bolt is not tightened, do the actions specified in
paragraph (h) of this AD before further flight. Repeat the detailed
inspection thereafter at intervals not to exceed 50 flight cycles
until the modification required by paragraph (h) of this AD is done.
    (1) For airplanes identified as Group 1 in Embraer Alert Service
Bulletin 145LEG-53-A032, Revision 01, dated September 24, 2013, on
which the actions of Embraer Service Bulletin 145LEG-53-0021, has
been done: Do the detailed inspection within 3,000 flight cycles
after accomplishment of the actions of Embraer Service Bulletin
145LEG-53-0021, or within 50 flight cycles after the effective date
of this AD, whichever occurs later.
    (2) For airplanes identified as Group 2 airplanes in Embraer
Alert Service Bulletin 145LEG-53-A032, Revision 01, dated September
24, 2013: Do the detailed inspection before the accumulation of
3,000 total flight cycles, or within 50 flight cycles after the
effective date of this AD, whichever occurs later.

(h) Modification

    Except as required by paragraph (g) of this AD, at the
applicable time specified in paragraphs (h)(1) or (h)(2) of this AD,
modify the attaching parts of the lower eyelet fitting of the
cockpit windshield center-post, including a general visual
inspection for any damage (cracks, dents, scratches) of the
specified lower eyelet fitting, in accordance with Part II of the
Accomplishment Instructions of Embraer Alert Service Bulletin
145LEG-53-A032, Revision 01, dated September 24, 2013. If any damage
is found during the general visual inspection, before further
flight, repair using a method approved by the Manager, International
Branch, ANM-116, Transport Airplane Directorate, FAA; or
Ag[ecirc]ncia Nacional de Avia[ccedil][atilde]o Civil (ANAC); or
ANAC's authorized Designee. If approved by the ANAC Designee, the
approval must include the Designee's authorized signature.
Accomplishment of the modification terminates the repetitive
inspections required by paragraph (g) of this AD.
    (1) For airplanes identified as Group 1 in Embraer Alert Service
Bulletin 145LEG-53-A032, Revision 01, dated September 24, 2013, on
which the actions specified in Embraer Service Bulletin 145LEG-53-
0021, has been done: Do the modification before the accumulation of
3,000 flight cycles after doing the actions specified in Embraer
Service Bulletin 145LEG-53-0021, or within 300 flight cycles after
the effective date of this AD, whichever occurs later.
    (2) For airplanes identified as Group 2 in Embraer Alert Service
Bulletin 145LEG-53-A032, Revision 01, dated September 24, 2013: Do
the modification before the accumulation of 3,000 total flight
cycles, or within 300 flight cycles after the effective date of this
AD, whichever occurs later.

(i) Credit for Previous Actions

    This paragraph provides credit for actions required by
paragraphs (g) and (h) of this AD, if those actions were performed
before the

effective date of this AD using Embraer Alert Service Bulletin
145LEG-53-A032, dated September 20, 2013, which is not incorporated
by reference in this AD.

(j) Other FAA AD Provisions

    The following provisions also apply to this AD:
    (1) Alternative Methods of Compliance (AMOCs): The Manager,
International Branch, ANM-116, FAA, has the authority to approve
AMOCs for this AD, if requested using the procedures found in 14 CFR
39.19. In accordance with 14 CFR 39.19, send your request to your
principal inspector or local Flight Standards District Office, as
appropriate. If sending information directly to the International
Branch, send it to ATTN: Todd Thompson, Aerospace Engineer,
International Branch, ANM-116, Transport Airplane Directorate, FAA,
1601 Lind Avenue SW., Renton, WA 98057-3356; telephone<PHONE_NUMBER>;
fax<PHONE_NUMBER>. Information may be emailed to<EMAIL_ADDRESS>Before using any approved AMOC, notify your
appropriate principal inspector, or lacking a principal inspector,
the manager of the local flight standards district office/
certificate holding district office. The AMOC approval letter must
specifically reference this AD.
    (2) Contacting the Manufacturer: For any requirement in this AD
to obtain corrective actions from a manufacturer, the action must be
accomplished using a method approved by the Manager, International
Branch, ANM-116, Transport Airplane Directorate, FAA; or ANAC; or
ANAC's authorized Designee. If approved by the ANAC Designee, the
approval must include the Designee's authorized signature.

(k) Related Information

    (1) Refer to Mandatory Continuing Airworthiness Information
(MCAI) Brazilian Airworthiness Directive 2013-10-02, dated October
23, 2013, for related information. This MCAI may be found in the AD
docket on the Internet at http://www.regulations.gov/#!documentDetail;D=FAA-2014-0234-0002.
    (2) Service information identified in this AD that is not
incorporated by reference is available at the addresses specified in
paragraphs (l)(3) and (l)(4) of this AD.

(l) Material Incorporated by Reference

    (1) The Director of the Federal Register approved the
incorporation by reference (IBR) of the service information listed
in this paragraph under 5 U.S.C. 552(a) and 1 CFR part 51.
    (2) You must use this service information as applicable to do
the actions required by this AD, unless this AD specifies otherwise.
    (i) Embraer Alert Service Bulletin 145LEG-53-A032, Revision 01,
dated September 24, 2013.
    (ii) Reserved.
    (3) For service information identified in this AD, contact
Empresa Brasileira de Aeronautica S.A. (Embraer), Technical
Publications Section (PC 060), Av. Brigadeiro Faria Lima, 2170--
Putim--12227-901 S[atilde]o Jose dos Campos--SP--BRASIL; telephone
+55 12 3927-5852 or +55 12 3309-0732; fax +55 12 3927-7546; email
<EMAIL_ADDRESS>Internet http://www.flyembraer.com.
    (4) You may view this service information at the FAA, Transport
Airplane Directorate, 1601 Lind Avenue SW., Renton, WA. For
information on the availability of this material at the FAA, call
425-227-1221.
    (5) You may view this service information that is incorporated
by reference at the National Archives and Records Administration
(NARA). For information on the availability of this material at
NARA, call<PHONE_NUMBER>, or go to: http://www.archives.gov/federal-register/cfr/ibr-locations.html.

    Issued in Renton, Washington, on August 7, 2014.
Victor Wicklund,
Acting Manager, Transport Airplane Directorate, Aircraft Certification
Service.
[FR Doc. 2014-19683 Filed 8-26-14; 8:45 am]
BILLING CODE 4910-13-P